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1 Introduction 


The IOA language provides notations for defining both primitive and composite I/O automata. 
This note describes, both formally and with examples, the constraints on these definitions, the 
composability requirements for the components of a composite automaton, and the transformation 
of a composite automaton into an equivalent primitive automaton. 

Section [2] introduces four examples used throughout this note to illustrate new definitions and 
operations. Section |3} treats IOA programs for primitive I/O automata: it introduces notations 
for describing the syntactic structures that appear in these programs, and it lists syntactic and 
semantic conditions that these programs must satisfy to represent valid primitive I/O automata. 
Section [4] describes how to reformulate primitive IOA programs into an equivalent but more regular 
(desugared) form that is used in later definitions in this note. Section |5} treats IOA programs 
for composite I/O automata: it introduces notations for describing the syntactic structures that 
appear in these programs, describes resortings induced by them, and lists syntactic and semantic 
conditions that these programs must satisfy to represent valid composite I/O automata. Section [6] 
describes the translation of the name spaces of component automata into a unified name space 
for the composite automaton. Section |7| shows how to expand an IOA program for a composite 
automaton into an equivalent IOA program for a primitive automaton. The expansion is generated 
by combining syntactic structures of the desugared programs for the component automata after 
applying appropriate replacements of sorts and variables. Section |8} details the expansion of the 
composite automaton introduced in Section |2| using the desugared forms developed throughout 
Sections [4}{6] and the techniques described in Section [7] Finally, Section [9] gives a precise definition 
of the resortings and substitutions used to replace sorts and variables. 

Nancy Lynch and Mandana Vaziri contributed to the design of the composition mechanisms 
described in this note. Dilsun Kaynar suggested numerous and substantial clarifications in the 
note’s presentation. 


2 Illustrative examples 


We use several examples of primitive and composite automata to illustrate both the notations 
provided by IOA and also the formal semantics of IOA. We refer to Examples throughout 


Sections Example [2.4] is relevant only to Sections 


Example 2.1 F igure [2.1]contains an IOA specification for a communication channel that can both 
drop duplicate messages and reorder messages. Type parameters for the specification, Node and 
Msg, represent the set of nodes that can be connected by channels and the set of messages that 
can be transmitted. Individual parameters, i and j, represent the nodes connected by a particular 
channel. 

Two features of this example warrant particular attention later in this note. First, the example 
uses both type and variable automaton parameters. Second, it uses the keyword const to indicate 
that the parameters i and j in the action signature are terms referring to the parameters i and j 
of the automaton, rather than fresh variable declarations. 


automaton Channel (Node, Msg:type, i, j:Node) 
signature 
input send(const i, const j, m:Msg) 
output receive(const i, const j, m:Msg) 
states contents:Set[Msg] := {} 
transitions 
input send(i, j, m) 
eff contents := insert(m, contents) 
output receive(i, j, m) 
pre m € contents 
eff contents := delete(m, contents) 


Figure 2.1: Sample automaton Channel 


Example 2.2 Figure [2.2] contains the specification for a process that runs on a node indexed by a 
natural number and that communicates with its neighbors by sending and receiving messages that 
consist of natural numbers. The process records the smallest value it has received and passes on all 
values that exceed the recorded value; if the set of values waiting to be passed on grows too large, 
the process can also lose a nondeterministic set of those values. Interesting features of this example 
include the use of terms as parameters in transition definitions and a local variable representing 
an initial nondeterministic choice and temporary state local to the transition. (The keyword local, 
newly added to the IOA language, replaces and extends the keyword choose formerly used to 
introduce hidden parameters. See Section [3] for a fuller description of local parameters. ) 


Example 2.3 Figure [2.3] contains the specification for another process that watches for overflow 
actions and reports those that meet a simple criterion. Interesting features of this example include 
more complicated uses of type parameters and where clauses, both in the action signature and to 
distinguish two transition definitions for a single action. 


Example 2.4 Finally, Figure[2.4|contains the specification of an automaton formed by composing 
instances of these three primitive automata. This specification relies on an auxiliary specification, 
shown in Figure [2.5] to define the term between(1, nProcesses). 


automaton P(n: Int) 
signature 
input receive(const n-1, const n, x:Int) 
output send(const n, const nt+i, x:Int), 
overflow(const n, s:Set[Int]) 


states 
val:Int := 0, 
toSend:Set[Int] := {} 


transitions 
input receive(n-1, n, x) 
eff if val = 0 then val := x 
elseif x < val then 
toSend := insert(val, toSend); 
val := x 
elseif val < x then 
toSend := insert(x, toSend) 
fi 
output send(n, n+1, x) 
pre x € toSend 
eff toSend := delete(x, toSend) 
output overflow(n, s:Set[Int]; local t:Set[Int]) 
pre s = toSend A n < size(s) At Cs 
eff toSend :=t 


Figure 2.2: Sample automaton P 


automaton Watch(T:type, what:Set[T]) 
signature 
input overflow(x:T, s:Set[T]) where x € what 
output found(x:T) where x € what 
states seen:Array[T,Bool] := constant (false) 
transitions 
input overflow(x, s U {x}) 


eff seen[x] := true 
input overflow(x, s) where “(x € s) 
eff seen[x] := false 


output found(x) 
pre seen[x] 


Figure 2.3: Sample automaton Watch 


axioms Between(Int, <) 


automaton Sys(nProcesses: Int) 
components C[n:Int]: Channel(Int, Int, n, n+1) 
where 1 <n An < nProcesses; 
P[n:Int] where 1 <n A n < nProcesses; 
W: Watch(Int, between(1, nProcesses)) 
hidden send(nProcesses, nProcessesti, m) 


invariant of Sys: 
Vom:Int V n:Int (1 <mAm<nAn < nProcesses 
=> P[m].val < P[n].val V P[n].val = 0) 


Figure 2.4: Sample composite automaton Sys 


Between(T, <:T,T-Bool): trait 
includes Set(T) 
introduces 
_-<__: T, T— Bool 
between: T, T — Set[T] 
asserts with x, y, z: T 


x € between(y, z) S y< xAx<z 


Figure 2.5: Auxiliary definition of function between 


3 Definitions for primitive automata 


In order to describe syntactic manipulations of IOA programs, we introduce a nomenclature for 
their syntactic elements. We expose just those elements of an IOA program we use to describe the 
expansion of composite automata into primitive form. Section introduces nomenclature for, 
and the meaning of, syntactic structures in primitive automata. Section [3.2] examines how states 
are represented and referenced in primitive IOA programs. Sections [3.3] and [3.4] describe semantic 
conditions that must hold for an IOA program to represent a valid primitive I/O automaton. 


3.1 Syntax 


Figure illustrates the general form of an IOA definition for a primitive I/O automaton. The 
figure exposes just those elements of an IOA program we use to describe the expansion of composite 
automata into primitive form. It does not expose the individual statements that appear in an eff 
clause. (These are treated separately in Section|9}) Rather the figure simply refers to the “program” 
(i.e., the complete sequence of statements) in an eff clause. 


automaton A(params“) 
assumes Assumptions 


signature 


input 1 (params*)"") where Pee 
output (params4;") where a 


Aw 
internal 7(params;,’") where par 


states stateVars4 := initVals“ initially Pos 


transitions 


A,r 
input 7(params:< 


deity) local case t; ) case t; where PP. t 


eff Progin”, ensuring ensuring," 


Ayr 
output a out,t;; local local Vars’, sar 1,) case tj where Pp ty 


pre Pre’ 


ot tj 


ff P i mgum 
e rogaim 4, ensuring ensuring git 1, 
Ayr A 
internal (params, 1,1 local local ars‘ t ) case t; where P;", 
obj 
pre Pre! 


in tj 


eff Pro ensuring ensuring” 
Te s I int,t; 


Figure 3.1: General form of a primitive automaton 


Notations and writing conventions 


In Figure params“ denotes the sequence of type and variable declarations that serve as the 

parameters of the automaton A. The Assumptions are LSL theories defining required properties 
: Ayr Ayr : ‘ . 

for these parameters. Notations params;,,, and params, , ty where kind is one of in, out, or 

int, denote sequences of variables and/or terms that serve as parameters for the action 7 and 


: ale ee ‘ Ayr A 
its transition definitions. The notations P; 4, Pint, 


Pina ty Pie ies and ensuringynd,t, denote 
predicates (i.e., boolean-valued expressions). The notation init Vals“ denotes the sequence of terms 
or choose expressions serving as initial values for the state variables. If the definition of A does 
not specify an initial value for some state variable, we treat the declaration of that state variable 


as equivalent to one of the form x:T := choose t:T where true. The notation Prog) ,, denotes 
bj 


a program. The notation localVars,o7) t denotes a sequence of variables. In general, a notation 
ending with an “s” denotes a sequence of zero or more elements. 

Our conventions for decorating syntactic structures throughout this paper are as follows. Su- 
perscripts refer either to automaton names or to automaton-name/action-name pairs. Automaton 
names are capitalized (e.g., A, C;, P). Action names are not capitalized and are either Greek letters 
(e.g., 7, 71) or written in mono-spaced font (e.g., send). Subscripts refer to more specific restric- 
tions such as action kind (i.e., in, out, or int), transition label (e.g., t1), or origin (e.g., desug). IOA 
keywords appear in a small-bold roman font. References to other text in sample IOA programs 
appear in a mono-spaced font. Syntactic structure labels and names in general IOA programs are 
italicized. 


Syntactic elements of primitive IOA programs 


Variables in IOA programs can be declared explicitly as automaton parameters (vars4, which is 
a subsequence of params“), as state variables (state Vars“), or as local variables (local Vars<o", a, 
they can also be declared implicitly as post-state variables that correspond to state variables, 
post-local variables corresponding to local variables, or by their appearance in action parame- 
ters (varsa™, which appear in params," ) or in transition parameters (varsint,» which appear in 
params‘): Variables in IOA programs can appear in parameters, terms, predicates, and pro- 
grams. For simplicity, Figure does not indicate which variables may have free occurrences in 
which parameters, terms, predicates, or programs; Section describes which can occur where. 
As an illustration, variables that occur freely in pA must be in one of the sequences vars“ or 
vars’. 

Below, we define each labeled syntactic structure and then illustrate it using selections from 


Examples 


Parameters 


e params“ is the sequence of formal parameters for A, which can be either variables or type 
parameters. We decompose params4 into two disjoint subsequences, one (vars) containing 
variable declarations and the other (types“) containing type parameters (identifiers qualified 
by the keyword type). For example, params”@*°® is (T:type, what:Set[T]), which consists 
of a type parameter T followed by a variable what :Set[T]. Hence typesWatch is (T:type) and 
varsWatch jg (what :Set[T]). 


® params<.", is the sequence of parameters for the set of actions of type kind named by 7 


in A’s signature. Action parameters can be either variables or const terms|!| For example, 


Channel,send . : F 
params; is (const i, const j, m:Msg). 


A . : ae bas 

e params sae i, 38 the sequence of terms serving as parameters for transition definition tj for 
actions of type kind named by 7. Whereas 7 can appear at most once as the name of an 
input, output, and internal action in A’s signature, it can have more than one transition 


definition as an input, output, and internal action. For example, params*2tch,overflow is 


an,ti 
Watch,overflow . 
is (x, s) 


(x, s U {x}) and params jn +, 


Variables 


A A 


e As noted above, vars” is the sequence of variables that are declared explicitly in params”, 
that is, vars“ is the sequence of identifiers in params“ qualified by some sort other than 
type/’| For example, vars®h@™mel is (i:Node, j:Node). 


An - : ; ' : Ayr 
e vars; is the sequence of variable declarations (i-e., non-const parameters) in params;,;",. 


Channel,send 


For example, vars," is (m:Msg). 


Channel is ( 


e state Vars“ is the sequence of state variables of A. For example, state Vars contents:Set [Msg]). 


e postVars“ is the sequence of variables for post-states of A that can occur in any ensuring), ty" 


These variables are primed versions of variables in stateVars4. For example, post Vars> is 
(val’:Int, toSend’:Set [Int] )P] 


Ayr . . . Ayr . A 
© VATS kind,t, 18 the sequence of variables that occur freely in params hindyty? but are not in vars”. 


P 


P,send . es 
is (x:Int), because n is in vars". 


For example, vars git +, 


e local Varst", ij is a sequence of additional local variables for transition definition t; for actions 
of type kind named 7; these variables are not listed as parameters of 7 in the signature of A. 


For example, localVarst overt tow is (t:Set[Int]). 


e localPost Varsi™ i is the sequence of post-local variables that name the values of local vari- 
ables after execution of Prog?” i These variables are primed versions of variables in 
local Vars*™, i, that appear on the left side of an assignment statement in the transition 


as ; Pe | 
definition and that can occur in ensuring;; 74 ;,+ 
obj 


"We may want to consider an alternative treatment for action parameters, similar to that for paramsyiny,t, that 
would dispense with the keyword const and treat all action parameters as terms, rather than as a mixture of terms 
and variable declarations. The current treatment allows factored notations, such as (i, j:Int), which introduce a list 
of variables of a given sort; the alternative treatment would require unfactored notations, such as 7(i:Int, 7:Int), in 
which a sort qualification applies only to the term it follows immediately. 

?When we define a sequence by selecting some members of another sequence, we preserve order in projecting from 
the defining sequence to the defined sequence. For example, if u:S precedes v:T in params“, then u:S' precedes v:T 
in vars“. 


3Previously, only the primed versions of state variables that appeared on the left side of an assignment statement 


in the transition definition were allowed to appear in an ensuring clause. For example, we defined post Varst Send 


to be (toSend’:Set [Int]), which did not include the variable val’, because val does not appear on the left side 
of an assignment in this transition definition. The more complicated definition was intended as a safeguard against 
specifiers writing val’ in an ensuring clause when there was no way the value of val’ could differ from that of 
val. However, the more complicated definition did not safeguard against all such errors, because specifiers could still 
write A’ .val in an ensuring clause. Hence the simpler definition appears preferable. 


Predicates 


® PAT is the where clause for the set of actions of type kind named by z in A’s signature. For 


1 pWatch,found 
example, out 


If action 7 does not appear as a particular kind—input, output, or internal—in A’s signature, 
then icra is defined to be false. 


is x € what. If Fare is not specified explicitly, it is taken to be true. 


° Pe is a predicate constraining the initial values for A’s state variables. If it is not specified 


explicitly, it is taken to be true. 


@ ae i is the where clause for transition definition t; for actions of type kind named by 7. 


Watch,overflow 


ie is n(x € s). If i 4 is not specified explicitly, it is taken 


For example, P 


to be true. If action 7 does not appear as a particular kind in A’s signature, then par, ‘i is 
defined to be false. 


e Pre, 7 is the precondition for transition definition t; for actions of type kind named 7, 


P,send . Ayr : ; 
out,t; 8 x € toSend. If Pre kind, t; is not specified 


explicitly, it is taken to be true. For every input transition, Pe is defined to be true 


because transition definitions for input actions do not have preconditions. 


where kind is out or int. For example, Pre 


e ensuring, 7 is the ensuring clause in the effects clause in transition definition ¢; for actions 
of type kind named a. If ensuring, ‘ is not specified explicitly, it is taken to be true. In 


the examples, all ensuring clauses are true by default] 


Programs and values 


® Progyemy, i is the program in the effects clause in transition definition ¢; for actions of type 


P,overflow 


out,t4 1s toSend := t. 


kind named 7. For example, Prog 


e initVals“ is the sequence of initial values for A’s state variables, which can be specified 
as either terms or choose expressions. A state variable without an explicit initial value is 
equivalent to one with an unconstrained initial value, that is, to one specified by a choose 
expression constrained by the predicate true. For example, init Vals? is (0, 4}). 


e z; is an optional identifier used to distinguish transition definitions of the same kind for the 
same action 7. If there is no case clause, t; is taken to be an arbitrary, but unique label] 


‘The keyword ensuring replaces the so that keyword, which has been removed from IOA. Formerly, so that 
was used to introduce three types of predicates in IOA: the initialization predicate for automaton state, the post-state 
predicate for transition definitions, and the loop variable predicate in for statements. This multiple use was confusing. 
Furthermore, the keyword where also introduces predicates, which led to additional confusion. In the new syntax, 
automaton state predicates are introduced by initially, post-state predicates are introduced by ensuring, and all 
other predicates (including for predicates) are introduced by where. The semantics of the clauses containing these 
predicates has not changed. 

°The case clause was introduced for use by the IOA simulator; it is not described yet in the IOA manual. 
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3.2. Aggregate sorts for state and local variables 
State variables 


The value (or the lvalue) of any state variable (e.g., toSend:Set[Int]) may be referenced using 
that variable (e.g., toSend) as if it were a constant operator (e.g., toSend: — Set [Int] |] How- 
ever, in contexts that involve more than a single automaton (e.g., simulation relations or composite 
automata), such variable references may be ambiguous. Hence IOA provides an equivalent, unam- 
biguous notation for the values of state variables. 

For each automaton A without type parameters, IOA automatically defines a sort States|Al], 
known as the aggregate state sort of A, as a tuple sort with a selection operator __.v:States|A] > T 
for each state variable v of sort T. IOA also automatically defines variables A and A’ of sort 
States|A] to represent the aggregate state and aggregate post-state of A. The terms A.v and A’.v 
are equivalent to references to the state variable v and to its value v’ in a post-state. For example, 
States[P] = tuple of val:Int, toSend:Set [Int], and P.val is a term of sort Int equivalent to the 
state variable val. 

If an automaton A has type parameters, the notation for its aggregate state sort is more 
complicated, because there can be different instantiations of A with different actual types, and a 
simple notation States|A] for the aggregate state sort would be ambiguous. To avoid this ambiguity, 
IOA includes the type parameters of A (if any) in the notation States[A, types“] for the aggregate 
state sort of A, and the aggregate state and post-state variables A have this sort States[A, types]. 
For example, States [Channel ,Node,Msg] = tuple of contents:Set [Msg], and Channel.contents is 
a term of sort Set [Msg] equivalent to the state variable contents. 

As we will see in Section [5.2| including type parameters in the name of the aggregate state sort 
enables us to generate distinct aggregate state sorts for each instantiation of A. 


Local variables 


In previous editions of the language, IOA introduced hidden action parameters with the keyword 
choose appearing subsequent to the where clause. Thus, hidden or choose parameters could not 
appear in the where clause. In the course of writing this document, we discovered a need for hidden 
parameters in the where clauses of desugared input actions (see Section|4). In addition, we believed 
that the ability to assign (temporary) values to hidden parameters would simplify the definitions 
of expanded transition definitions of composite automatal"| We introduced local variables into 
IOA to serve both these purposes. Local variables replace and extend choose parameters. Thus, 
the keyword local replaces the keyword choose in transition definition parameter lists and local 
variables are those introduced following the keyword local in these parameter lists. 

In the new notation, the scope of local variables extends to the whole transition definition, not 
just to the precondition and effects. In addition, local variables may be assigned values in the eff 
clause. Semantically, local variables are not part of the state of the I/O automaton represented 
by an IOA program. Rather, they define intermediate states that occur during the execution of 
an atomic transitions, but are not visible externally. Therefore, local variables may not appear in 
simulation relations or invariants. 

Although local variables differ significantly from state variables in terms of semantics, their 
syntactic treatment is similar. As for state variables, IOA automatically defines an aggregate local 


°An unambiguous variable identifier can be used alone. If two variables defined in the same scope have the same 
identifier, but different sorts, their identifier may need to be qualified by their sorts. 

In the end, our final definitions in Sections|7.6]{7.5]do not to use this feature. However, the ability to assign to 
local variables was deemed useful and remains in the language. 
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sort, together with aggregate local and post-local variables, to provide a second, equivalent notation 
for references to local and post-local variables. For every transition definition t; for an action 7 of 
type kind in automaton A, the aggregate local sort Locals[A, types“, kind, 7, t;] is a tuple sort with 
a selection operator __.v:States|A] — T for each local variable v of sort T. Furthermore, aggregate 
local and post-local variables, A and A’ of sort localVars;2", 4,1 are defined in the scope of that 
transition definition. If there is only one transition definition for an action 7 of type kind, we omit 
t; in the notation for this sort. For example, the aggregate locals sort Locals|P, out ,overflow] is 
tuple of t:Set[Int], and P.t is a term of sort Set [Int] equivalent to the local variable t in the 
scope of overflow. 

Note that the automaton name A is used as the identifier for two aggregate variables in ev- 
ery transition definition: A:States[A, types] and A:Locals[A, types“, kind, 7, t;]. As specified in 
ee stateVars“ and local Vars‘iing 1, must have no variables in common. Therefore, the 
aggregate sorts have no selection operators in common and there is no ambiguity. 

The initial values of local variables are constrained by the where predicate of the declaring 
transition definition. In particular, a transition kind m(...) case t; is defined only for values of its 
parameters that 


1. satisfy the where clause of that kind of 7 in the signature of A, and 


2. together with some choice of initial values for its local variables, satisfy the where clause of 
the transition definition. 


A transition is enabled only for the values of its parameters and local variables for which it is 
defined and for which the precondition, if any, is satisfied. 

Thus, the initial values of local variables are chosen nondeterministically from among the values 
that meet these constraints. Local variables serve as hidden parameters with the semantics formerly 
applied to choose parameters. We provide a formal treatment of the “values of its parameters” 
and “some choice of values” at the end of Section [4] 


Example 3.1 The type declarations and variables automatically defined for the sample automata 
Channel, P, and Watch are shown in F igure 3.2] 


type States[Channel,Node,Msg] = tuple of contents:Set [Msg] 
type States[P] = tuple of val:Int, toSend:Set[Int] 
type States[Watch,T] = tuple of seen:Array[T, Bool] 
type Locals[P,out,overflow] = tuple of t:Set[Int] 


Channel: States[Channel, Node, Msg] 
P: States [P] 

Watch: States[Watch,T] 

P: Locals[P,out,overflow] 


Figure 3.2: Automatically defined types and variables for sample automata 


3.3. Static semantic checks 


The following conditions must be true for an IOA program to represent a valid primitive I/O au- 
tomaton. These conditions, which can be checked statically, are currently performed by ioaCheck, 
the IOA parser and static-semantic checker. 
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LOCATION OF TERM | VARIABLES THAT CAN OCCUR FREELY IN TERM 
params“ vars“ 
A,r A Ayr 
params, 4 vars”, vars), 4 
Ayr A Ayr 
Prind vars”, VATS pq 
init Vals4 vars’ 
A A A 
P init vars”, state Vars 
Ayr A Ayr 
PATAMS kind t, vars”, VATS gind,t, 
Ayr A Ayr Ayr 
Piind,t; vars, VATS kind t;? local Varsi.ina,t; 
Ayr A Ayr Ayr A 
Pre kind t; vars®, UOTS hind,t;> local Vars pind t;) state Vars 
A,r A Ayr Ayr A 
Prog hind, t; vars, VATS kind t;? localVarsiing,t;: state Vars 
A A 
hae vars“, vars,", ,, localVars;.", ,, stateVars4, 
ENSUTING pdt a a 
on ostVars“, localPost Vars" 
D ’ kind, tj 


Table 3.1: Variables that can occur freely in terms in the definition of a primitive automaton. 
Variables listed on the right may occur freely in the syntactic structure listed to their left. 


Vv No sort appears more than once in types”. 


A 


¥Y Each action name (e.g., 7) occurs at most three times in the signature of an automaton: at 


Vv 


most once in a list of input actions, at most once in a list of output actions, and at most once 
in a list of internal actions. 


Each occurrence of an action name (e.g., 7) in the signature of an automaton, or in one of 
its transition definitions, must be followed by the same number and sorts of parameters. 


A : : . 

The sequences vars“ and vars hing Of variables contain no duplicates; furthermore, no variable 
A 

appears in both vars“ and vars hing for any value of kind|'| 


For each transition definition ¢; for an action of type kind named 7, no variable appears more 


A 


. ; : A 
than once in the combination of the sequences vars”, state Vars4, post Vars4, vars Se ies 
aby 


Ayr Ayr 
local Vars ina, t;> and localPost Vars hindt;* 
For each transition definition t; for an action of type kind named 7, and for any identifier vu 


and sort S, the sequences state Vars“ and local Vars‘*™, t do not contain both of the variables 
u:S and v':S. 


Any operator that occurs in a term used in the definition of an automaton must be introduced 
by a type definition or axioms clause in the IOA specification that contains the automaton 


’This restriction is designed to avoid the confusion that would result if variables in vars”, are allowed to hide 
or override variables with the same identifiers and sorts in vars“. A stronger restriction would prohibit an identifier 
from appearing in two different variables (of different sorts) in vars“ and vars’; this restriction would avoid the 
need to pick a fresh variable when an instantiation of A causes two variables with the same identifier to clash by 
mapping their sorts to a common sort. However, IOA does not make this stronger restriction. 
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definition, by a theory specified in the assumes clause of the definition, or by a built-in 
datatype of IOA. 


Vv Any variable that occurs freely in a term used in the definition of an automaton must satisfy 
the restrictions imposed by Table 


3.4 Semantic proof obligations 


The following conditions must also be true for an IOA program to represent a valid I/O automaton. 
Except in special cases, these conditions cannot be checked automatically, because they may require 
nontrivial proofs (or even be undecidable); hence static semantic checkers must translate all but the 
simplest of them into proof obligations for an automated proof assistant. These proof obligations 
must be discharged using the axioms provided by IOA’s built-in types, by the theories associated 
with the type definitions and the axioms in the IOA specification that contains the automaton 
definition, and by the theories associated with the assumes clause of that definition. 


V The sets of input, output, and internal actions in an I/O automaton must be disjoint. Thus, 
for each sequence of values for the parameters of an action named 7 in the definition of an 


A A A 
automaton A, at most one of Pj", Po", and P;.\" can be true. 


Special cases arise if two of the three signature where clauses for 7 are literally false or if 
two of three clauses are literally true. In the former case, the check automatically succeeds; 
in the latter, it automatically fails. 


Vv There must be a transition defined for every action specified in the signature. Thus, for 
each sequence of values for the parameters of an action named 7 that make oe true, there 
must be a transition definition t; for 7 of type kind such that po 7 is true for these values 


together with some values for the local variable of that transition definition. 


¥ For each kind of each action 7, at most one transition definition ¢; can be defined for each 
sequence of parameters values. That is, for each sequence of values, pan, 4, can be true for 
at most one value of j. 


Special cases arise if all but one of the transition definition where clauses for a kind of an action 
are literally false or any two are literally true. In the former case, the check automatically 
succeeds; in the latter, it automatically fails. 


We define these proof obligations more formally at the end of Section 
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4 MDesugaring primitive automata 


The syntax for IOA programs described in Section [3] allows some flexibility of expression. However, 
when defining semantic checks and algorithmic manipulations (e.g., composition) of IOA programs, 
it is helpful to restrict attention, without loss of generality, to IOA programs that conform to a 
more limited syntax. 

In this section, we describe how to transform any primitive IOA program (as in Figure 
into an equivalent program (Figure written with a more limited syntax. We describe this 
transformation in four stages. First, in Section [4.1] we show how to desugar terms that appear as 
parameters by replacing them with variables constrained by where clauses; that is, we show how 
to reformulate action and transition definitions so as to eliminate the use of terms as parameters. 
Second, in Section [4.2| we show how to introduce canonical parameters into desugared actions and 
transition definitions. A canonicalized action is parameterized by the same sequence of variables 
in all appearances, both in the signature and in the transition definitions. Third, in Section 
we combine all transition definitions of a single kind of an action into a single transition definition. 
Fourth, in Section we convert each reference to a state variable x to the equivalent reference 
A.x defined in Section .2] In Section [4.5} we summarize the effects of these desugarings, which are 
illustrated in Figure Finally, in Section we use the result of the first two transformations 
to formalize the semantic proof obligations introduced in Section [3 


4.1 Desugaring terms used as parameters 
Signature 


We desugar const parameters for an action in A’s signature by introducing fresh variables and 
modifying the action’s where clause. For each const parameter we introduce a fresh variable and 
add a conjunct to the where clause that equates the new variable with the term that served as the 
const parameter. For example, if ¢ is a term of sort T, then we desugar the action 


input (vars, const t) where Pee 
as 


input (vars ,v ,u:T) where v=t A Pe 


Here, v:T' is a fresh eae that is, one that does not appear in vars4, varsi™ 


on 3 state Vars“ 


or localPost Vars4*™ for any j 


A 
postVars“, local Vars@ int; 


Let Pe ,desug 


been desugared. Let varsii", dang be the sequence of distinct variables that parameterize 7 after 


nas 


be the where predicate that results after all const parameters in params*;", have 


desugaring. Note that all variables that occur freely in Pe are either in vars, ig in 


hind ,desug 
A,r Ayr : ‘ 2 
vars“. In general, vars . ibalig is a supersequence of vars;,;", (in that it contains a fresh variable 


: A : 
for each const parameter in params a In the above example, a const parameter appears in 


°For the purposes of this transformation, it suffices to pick some v:T that does not appear in either vars“ or 
varse™, However, by ensuring that v:T is distinct from additional variables, we avoid having to replace it by yet 
another fresh variable when we introduce canonical transition parameters, as described in Section [4.2 Furthermore, 
to avoid any ambiguity that may arise when two variables share an identifier, and to avoid having to replace v:T by 
yet another fresh variable in an instantiation of A that maps T and the sort of another variable with identifier v to a 
common Bort it is helpful to pie v to be an identifier that does not appear in vars“, varsa’ , state Vars“, post Vars“, 


localVars*:”., or localPostVars:”, for any j. 


int? mh 
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automaton A(types4, vars“) 


signature 


Ayr Ayr Ayr = Ayr 
input m(vars;’ cn) where Pi) A varsin desug = PATams;,, 
Ayr Ayr Ayr == Ayr 
output m(vars? 7) desug) Where Pais A vars.) desug = PATAMS out 
Ayr wT Ayr Ayr 
internal 7(vars;"" ‘desug) Where Poy A vars?" desug = PATAMS;, 
states state Vars4 := initVals“ initially Pe, 
transitions 
A,r A,r 
input (varsin dena local local Vars‘ ne VATS in ) case t; 
? A,r a Ayn 
where Poe A VATS in. t,,desug = PATAMS;,) 4, 
fF P Ayr : Ayr 
eff Prog;,,;, ensuring ensuring, 4. 
output m(vars“* local localVars‘" , , vars“ ) case t; 
P out,t; ,desug? out, tj? out,t; J 
A,r Ayr 
where eae t; A vars oat pastie= = params oy t; 
pre Pre me ” 


’ s ~ A,r 
eff Prog ext t ensuring ensuring out 4, 


Ayn 
local local Vars‘, au t; , VATS inf ,) case ty 


Ayr 
int tj 


internal m(varsa* 
int tj ,desug? 


Ayr 
/\ vars 


where ie ine ,tj,desug 


ae t; = params 


pre Pre! 


a tj 


eff Prog ey ensuring ensuring." ce 


Figure 4.1: Preliminary form of a desugared primitive automaton: all action parameters are vari- 
ables 
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the last position of params‘). In general, const parameters may appear in any position. A fresh 
: : A : us ; : 
variable appears in vars;,’", aig the same position the const parameter it replaces appears in 
params‘). 
The preliminary form for desugaring an automaton signature shown in Figure indicates 
that each variable i ay ted to th ding entry i a" (In th 
at each variable in varsyinq.desug 18 equated to the corresponding entry in params;,;,,- (In the 
figure, we use params," to mean the sequence of terms without the const keyword.) An obvious 


simplification is to omit any identity conjuncts that arise when a variable in vars", is equated to 
itself. 


Transition definitions 


We desugar the parameters for each transition definition for an action named 7 to eliminate pa- 

rameters that are not just simple variable references|"| As shown in Figure we first replace 

the transition parameters params/", , by references to distinct fresh variables vars” that 
p D kind, t; y kind,t; ,desug? 


: : : A A A A,r Ayr 
is, to variables that do not appear in vars”, stateVars”, postVars”, vars hindyty? local Vars kind,t;1 OF 


localPostVars,o") ee we maintain the original semantics of the transition definition by 
adding conjuncts to the where clause to equate the new variables with the old parameters. Third, 
because transition definition parameters may introduce variables implicitly, but where clauses may 
not, we introduce the previously free variables (i.e., vars) re) as additional local variables, letting 


A : A A 
local Vars Fred be desig be the concatenation of local Vars hind and vars ands In effect, these steps 
move terms used as parameters into the where clause. For example, if ¢ is a term and v is a fresh 
variable with the same sort as t, then we desugar the transition definition 


input 7(t) where fara 
as 
° Ayr A,r 
input 7(v; local VATS in +.) where v=t A P;y, 
Let PA” be the where predicate that results after transition parameters have been 


kind,t; ,desug 

desugared in this fashion. Then any variable that has a free occurrence in this predicate must be 

: A Ayr Ayr 
in vars”, VATSkind,t;,desug? OT local Vars jind,t;,desug’ 
After const and transition definition terms have been desugared, the valid occurrences of free 
variables in syntactic forms, shown in Table is revised by those shown in Table After 

. Ayr Ayr Ayr = A,r 
desugaring, params; , = VATS ind, desug and PATAMS ind t, = VBS gind,t; desug’ 
Example 4.1 The first step in desugaring the primitive automata defined in Figures is 
shown in Figure[4.2] For the automaton Channel, n1:Node and n2:Node are fresh variables introduced 


to desugar the const parameters in the signature. Similarly, n1i:Node, n2:Node, and m1:Msg are 


10As mentioned in Footnote [I] we distinguish between action parameters in the signature that are terms (const 

parameters) and those that are variable declarations to provide strong typing for variable declarations. Since the sorts 
A,r : A,r : ai ie . ‘ ee 

of params;,;,, determine the sorts of params kind,t;? there is no need for such a distinction in transition parameters. 

‘Tt suffices to replace just those parameters that are not simply references to variables, because the fresh variables 
corresponding to such terms disappear when we substitute references to canonical variables for the parameters, as 
described in the next section. However, the replacement is easier to describe if we replace all parameters. 

Furthermore, as for const parameters, to avoid any ambiguity that may arise in the where clause when two 
variables share an identifier, and to avoid having to replace v:T by yet another fresh variable in an instantiation of 
A that maps T and the sort of another variable with identifier v to a common sort, it is helpful to pick v to be an 
identifier that is not in vars“, stateVars“, postVars“, vars{y", ,., localVars{;", ,., or localPostVars¢.”, ,.. 

a] obj obj 
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LOCATION OF TERM | VARIABLES THAT CAN OCCUR FREELY IN TERM 


par A Ayr 
kind, desug UGES 3 UKs kind, desug 
A,r A 


vars4, vars4™ localVars“17 
’ kind,t; ,desug’ kind,t;, 


kind,t; ,desug desug 


Table 4.1: Variables that can occur freely in terms in the definition of a desugared primitive 


automaton. Variables listed on the right may occur freely in the syntactic structure listed to their 
left. 


Channel,send 
and 


fresh variables introduced to desugar transition parameters. Since both vars;, 4, 


Channel,receive : . ‘ : ; 
VATS outt, contain the single variable m:Msg, we introduce m:Msg as a local variable for each 
> 


transition definition. Notice that the variables introduced for each action need be fresh only with 
respect to i:Node, j:Node, and m:Msg; furthermore, “freshness” need not extend across transitions 
or between actions and transitions. 

The automata P and Watch are desugared in a similar fashion. Since there are no const parame- 
ters in the signature of Watch, that signature is unchanged. Since the parameters for the transition 
definitions for the overflow action in Watch contain two free variables, x and s, the desugared tran- 
sition definitions declare these variables as local. Also, in the second of the desugared transition 
definitions, the desugared where clause incorporates the original where clause as a conjunct. 


4.2 Introducing canonical names for parameters 


Signature 


F : A A, A 
IOA does not require that the sequences of variables vars;’", vars<7;, and vars,” be the same. For 


example, const parameters may cause these sequences to have different lengths. However, since IOA 


: Ayr Ayn A,r : 
requires params, , params,,,, and params,,, to contain the same number and sorts of elements, 
P 7 Ayr Ayr Ayr 
the desugared versions of these sequences (i.e., UGTS in desugs VETS ont. desugs and VATS int desug) do have 


the same number and sorts of elements. We choose one of these desugared variable sequences to 
be the canonical parameters for the action 7 in A. We call the canonical sequence vars4™. We 
replace the other two sequences of parameters for 7 in the signature of A by vars“, and we define 


j j A,r A,r ; Ayr 1 A,r 12 
substitutions 07," , to replace VATS hind, desug with vars” in P.. a 


Transition definitions 


We canonicalize the parameters for each transition definition for an action named 7 so that the 
definition also uses vars“’™ as its parameters. Specifically, we replace the references to variables 
that parameterize a desugared transition definition of 7 (i.e., varse7) ty, aa by references to 
the canonical variables (i.e., vars4") throughout the transition definition. Therefore we define a 
substitution a ; to perform this replacement and apply it to the whole transition definition. 
As described in Section [9} if the canonical variables clash with the desugared local variables (i.e., 
localVars(2", iten ar we must substitute fresh local variables for those that clash. The variables 


introduced by the substitution must be be distinct and fresh with respect to vars“, vars“:7, and the 


See Section|9] for a precise definition of a substitution, which maps a set of variables to a set of terms. Often we 
represent the domain and range of a substitution as sequences, with the ith variable in the domain being replaced by 
the ith variable or term in the range. 
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automaton Channel(Node, Msg:type, i, j:Node) 


signature 
input send(n1, n2:Node, m:Msg) where ni =i A n2 = j 
output receive(ni, n2:Node, m:Msg) where ni = i A n2 = j 
states contents:Set[Msg] := {} 
transitions 
input send(n1, n2, mi; local m:Msg) where nt =i A n2=j Ami =m 
eff contents := insert(m, contents) 
output receive(ni, n2, mi; local m:Msg) 
where nt =i A n2=jAnmit=m 
pre m € contents 
eff contents := delete(m, contents) 


automaton P(n:Int) 


signature 
input receive(il, i2, x:Int) where it = n-1 A i2=n 
output send(il, i2, x:Int) where il =n A i2 = ntl, 
overflow(il:Int, s:Set[Int]) where ii =n 
states 
val:Int := 0, 
toSend:Set[Int] := {} 


transitions 
input receive(il, i2, i3; local x:Int) 


where it = n-1 A i2=nAi3 =x 

eff ... % effect clause unchanged from original definition of P 
output send(iil, i2, i3; local x:Int) 

where it =n A i2=ntiAi3 =x 

pre x € toSend 

eff toSend := delete(x, toSend) 
output overflow(iit, st; local t, s:Set[Int]) where il =n A st=s 

pre s = toSend A n < size(s) At Cs 

eff toSend :=t 


automaton Watch(T:type, what:Set[T]) 
signature 
input overflow(x:T, s:Set[T]) where x € what 
output found(x:T) where x € what 
states seen:Array[T,Bool] := constant (false) 
transitions 
input overflow(t1, si; local x:T, s:Set[T]) 
where ti = x A si =s U {x} 
eff seen[x] := true 
input overflow(t1, si; local x:T, s:Set[T]) 
where =(x € s) Ati =xA st=s 
eff seen[x] := false 
output found(ti; local x:T) where ti = x 
pre seen[x] 


Figure 4.2: Preliminary desugarings of the sample automata Channel, P, and Watch 
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automaton A(types“, vars“) 


signature 


Ayr ) 
in, desug 


output 7(vars4") where ae) 


A A, 
af) where Ce Pint desig) 


input 7(vars“:") where of: ae ig 
internal (vars 


states stateVars“ := initVals“ initially P/,, 


transitions 
A,r 
ae input moar Sint econ local localVars‘)", Josea) case t; where Py deans 
in, ty 


eff Prog’ ensur ing™ 
TOJin 1, CHSU ing ENSUTING int, 


output (vars local local Vars“) case t; where pA 


ay deena) 


out,t; ,desug? ae ,desug 
Ayr 
© out ,t; pre Pret tj 
eff Prog’ ensuring ensurin | 
za sty J out, tj 
Ayr 
internal (vars doulas local localVars‘ ond) case t; where Pate Geaiy 
Ayr 


eff Pro eee ensurin ae 
Vt sn g I int,,t, 


Figure 4.3: Intermediate form of a desugared primitive automaton with canonical action parameters 


(cf. Figure 


desugared local variables. The substitutions for canonicalization are listed in Table Variables 
listed in the center column are mapped by the substitution named in the left column to those listed 
in the right column. 


Simplifying local variables 


Finally, we simplify each desugared and canonicalized transition definition for actions named 7 by 
eliminating extraneous local variables. A local variable may be eliminated if it is never an lvalue in 
an assignment in the transition definition for 7 and if the where clause equates it with a canonical 
variable for 7, that is, if it is used only as a constant in the transition definition and is already 
named by a canonical parameter. 

This simplification is accomplished in four steps. 


1. Define a substitution on dtr that maps the redundant local variables to the corresponding 
canonical variables. 


2. Apply ae ric atthe to each clause in the transition definition: the where, pre, eff, and ensuring 
clauses. 
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SUBSTITUTION | DOMAIN RANGE 
Ayr Ayr Ayr 
O kind VATS bind desug UGTS 
A,r A,r Ayr 
T kind, tj vars kind,t; ,desug vars 
A,r : : A,r A,r Ayn 
O vind di irre Redundant variables in Crind,t, local Vars ind,t; ,desug) vars 
ax € stateVars4 A: States[A, types“].a 
oA a! € post Vars4 A’: States[A, types“].x 
A,r . A 
LE local Vars jina,t A:Locals|A, types” , 1]. 
q Ayr i A 
a € localPostVarsj ina, A':Locals|A, types“, 7].x 


Table 4.2: Substitutions used in desugaring a primitive automaton. Substitutions listed on the left 
map variables in the domain to their right to variables in the range their far right. 


3. Delete identity conjuncts from the where clause. 


4. Delete the declarations of local variables that no longer appear in the transition. 


Example 4.2 The second step in desugaring the primitive automata defined in Figures 2. 1}{2.3] is 
shown in Figure[4.4| The definitions in this figure are obtained from those in F igure [4.2] by selecting 
canonical parameters for each action. 

Since each action occurs only once in the signature of the automaton Channel, selecting the 
canonical variables is trivial: 


Ch 1 d Channel,send _ 
e varsvnanne:, sene defaults to WGI S se cdasun = (n1:Node, n2:Node, m:Msg), and 


Channel,receive Channel,receive _ : . . 
e vars defaults to VOUS out dasng = (n1:Node, n2:Node, m:Msg). 


These selections also make canonicalizing the signature trivial, because identity substitutions suffice. 
We canonicalize the transition definitions by defining two substitutions. 


oo maps Urs do = (ni:Node, n2:Node, mi:Msg), to vars 


replacing the parameter mi:Msg with the canonical parameter m:Msg. To avoid a conflict 
between the local variable m:Msg and the canonical parameter m:Msg, the substitution also 
replaces m:Msg by the fresh variable m2:Msg. 


. Channel,send by 


Channel ,receive Channel,receive 
out,t4 maps vars out,t1 ,desug 


to varsChannel receive hy replacing the parameter m1:Msg with the canonical parameter m:Msg 
and the local variable m:Msg with the fresh variable m2:Msg. 


e In the same way, o = (n1:Node, n2:Node, m1:Msg) 


Applying these substitution to the transition definitions produces 
input send(n1, n2, m; local m2:Msg) where ni = i A n2 = j A m= m2 


eff contents := insert(m2, contents) 

output receive(ni, n2, m; local m2:Msg) where ni = i A n2=j A m= m2 
pre m2 € contents 
eff contents := delete(m2, contents) 
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automaton Channel (Node, Msg:type, i, j:Node) 


signature 
input send(ni, n2:Node, m:Msg) where ni = i A n2 = j 
output receive(ni, n2:Node, m:Msg) where ni = i A n2 = j 
states contents:Set[Msg] := {} 
transitions 
input send(n1, n2, m) where ni =i A n2 = j 
eff contents := insert(m, contents) 
output receive(ni, n2, m) where ni =i A n2 = j 
pre m € contents 
eff contents := delete(m, contents) 


automaton P(n: Int) 
signature 
input receive(il, i2, x:Int) where it = n-1 A i2=n 
output send(iil, i2, x:Int) where il =n A i2 = ntl, 
overflow(il:Int, s:Set[{Int]) where ii =n 
states 
val:Int := 0, 
toSend:Set[Int] := {} 
transitions 
input receive(il, i2, x) where it = n-1 A i2=n 
eff if val = 0 then val := x 
elseif x < val then 
toSend := insert(val, toSend); 
val := x 
elseif val < x then 
toSend := insert(x, toSend) 
fi 
output send(il, i2, x) where i1 =n A i2 = n+l 
pre x € toSend 
eff toSend := delete(x, toSend) 
output overflow(i1t, s; local t:Set[Int]) where it =n 
pre s = toSend A n < size(s) At Cs 
eff toSend := t 


automaton Watch(T:type, what:Set[T]) 
signature 
input overflow(x:T, s:Set[T]) where x € what 
output found(x:T) where x € what 
states seen:Array[T,Bool] := constant (false) 
transitions 
input overflow(x, s; local s2:Set[T]) where s = s2 U {x} 


eff seen[x] := true 
input overflow(x, s) where “(x € s) 
eff seen[x] := false 


output found(x) 
pre seen[x] 


Figure 4.4: Intermediate desugarings of the sample automata Channel, P, and Watch, obtained from 
the preliminary desugarings in Figure [4.2] by selecting canonical parameters for each action 
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However, the local variable m2 is extraneous in both transition definitions, because it is equated with 
m in the where clause and no value is assigned to it. Hence m2 equals m throughout the transition, 
i F é ; ‘ F channel,send : 
and we can eliminate it entirely by applying a substitution (e.g., Oe, dann , which maps m2 to 
m) to the where, eff and pre (in the case of receive) clauses and simplifying the result, as shown in 


Figure 
As for Channel, each action occurs only once in the signature of the automaton P. Hence, it is 


trivial to select vars?:-TeC*iVe yarsPSeM4 and varsP:°Vertlow and to canonicalize the signature. 
P,receive P,receive 


To map ORE ae (ie., (i1:Int, i2:Int, i3:Int)) to vars , we define oj," 5, 
to replace i3:Int by x:Int. To avoid conflicts between the local variable x:Int and the canonical 
parameter x:Int, the substitution also replaces x:Int by i4:Int. Applying this substitution to the 


transition definition produces: 


input receive(il, i2, x; local i4:Int) where i1 = n-1 A i2=nAx= i4 
eff if val = 0 then val := i4 

elseif i4 < val then 
toSend := insert(val, toSend); 
val := 14 

elseif val < i4 then 
toSend := insert(i4, toSend) 

fi 


Since the local variable i4 equals x throughout the transition definition, we can eliminate it entirely 
by defining a substitution mapping i4 to x, applying that substitution to the where and eff clauses, 
and simplifying the result, as shown in Figure 

Canonicalization of the send transition follows the same pattern as the receive transition. 


Application of the canonicalizing substitution Cee yields: 


output send(il, i2, x; local i4:Int) where it =n A i2= nti A x= i4 
pre i4 ©€ toSend 
eff toSend := delete(i4, toSend) 


This definition simplifies to the one shown in Figure which does not contain a local variable. 
Poverflow 
out, ty 


output overflow(iit, s; local t, s2:Set[Int]) where it =n A s = 82 

pre s2 = toSend A n < size(s2) A t C s2 

eff toSend :=t 
Once again, this definition simplifies to the one shown in Figure [4.2] Notice that the local variable 
t cannot be eliminated because it is not equated with a canonical parameter. Further notice that, 
in this case, canonicalization has eliminated all the local variables introduced in the desugaring 
step. 

As for Channel and P, each action occurs only once in the signature of the automaton Watch. 

Hence it is trivial to select varsWatch.overflow ang yarsWatch,found 


Similarly applying the canonicalizing substitution o to the overflow transition yields: 


watch,overf low 


Canonicalizing the two transition definitions for overflow proceeds by defining o;;,, /’ 


and a ala which happen to be the same. They map t1:T to x:T, si:Set[T] to s:Set[T], 


s:Set[T] to s2:Set[T], and x:T to t2:T. Applying these substitutions to the transition definitions 
yields: 
input overflow(x, s; local t2:T, s2:Set[T]) 
where x = t2 A s = s2 U {t2} 
eff seen[t2] := true 
input overflow(x, s; local t2:T, s2:Set[T]) 
where =(t2 € s2) Ax =t2As = 82 
eff seen[x] := false 
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The local variable t2:T can be eliminated from both transition definitions. The local variable 
s2:Set[T] can be eliminated from the second transition definition but not from the first. These 
simplifications result in the transition definitions shown in Figure 

Notice that after the simplification of the local variable, the semantic meaning of the parameter 
s:Set[T] in the desugared and canonicalized automaton shown in Figure [4.4] is different than the 
meaning of the parameter s:Set[T] in the original automaton shown in Figure [2.3] The parameter 
s:Set[T] in the original actually corresponds to the local variable s2:Set[T] in the canonicalized 


version. 
watch,found 
aris ty 


output found(x; local t2:T) where x = t2 
pre seen[t2] 
After its local variables are simplified, the transition definition shown in Figure [4.4] is identical to 
the one originally defined in Figure [2.3] 


Applying the canonicalizing substitution o to the found transition yields: 


4.3. Combining transition definitions 


We will see in Sections[7.7]{7.9] that combining multiple transition definitions for a given action into 
a single transition definition is useful for composing automata. It is necessary for combining input 
actions that execute atomically in the composition, and it avoids a code explosion multiplicative in 
the number of input and output actions. Because this transition combining step is easy to under- 
stand when applied to a single primitive automaton, we describe it here and assume all automata 
hereafter have only a single transition definition per kind per action, as shown in Figure To 
combine the transition definitions for a given kind of an action 7, we need to combine their se- 
quences of parameters, their local variables, and their where, pre, eff, and ensuring clauses into 
one, semantically equivalent, transition definition. 

Furthermore, as will be discussed further in Section |7| the kind of an action may be changed 
by composition. Input actions may be subsumed by output actions, and output actions may be 
hidden as internal actions. Thus, the expansion of a composite automaton may combine transition 
definitions across kinds. To facilitate such combinations, we collect together all the local variables 
for each action of an automaton A into a single sequence of variables local Vars“:*, which is the 
concatenation (with duplicates removed) of the all sequences local Vans: Again, this variable 
combining step is easy to understand when applied to a single primitive automaton, so we describe 
it here and assume all automata hereafter have only one sequence of local variables per action 
name. 

In describing this combination, we assume that parameters of the automaton have already 
been desugared and canonicalized as described in Sections and In Figure and the 
discussion below, we indicate the syntactic forms that result from that desugaring by use of the 
desug subscript. We rely on the key semantic condition (mentioned in Section and discussed 
in Section that exactly one transition definition be defined for each assignment of values to 
vars“ that satisfies Pt, That is, within an automaton, all like-named transition definitions 
must have where clauses that are satisfiable only for disjoint sets of parameter values|™] 

First, notice that since all the contributing transition definitions are already desugared and 
canonicalized, each is is parameterized by vars“*". Hence, combining the parameters is trivial. 

At first glance, combining local variables looks trickier. Each transition definition has local 
scope with respect to local variables. So, there may be any amount of duplication of variables 


These semantic conditions also ensure that, in the absence of local variables, the resulting where clause can be 
eliminated because it will be equivalent to true. 
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automaton A(types4, vars“) 


states state Vars4 := init Vals“ initially ee(Pe 


transitions 
< ‘ Ayr. ] 1 local Vars“* ) wh par 
inpu 7 (vars ; 10Cal Loca: Vars )w ere Vj in,t; ,desug 
eff 
. Ayr Ayr 
if Pts estig then POD ict. eetg 
elseif ... 
fi 
° Ayr 7 A,r 
ensuring \; (fea = ensuring’y”, desu) 


Ayr 


A,r. A,r 
output 7(vars“"; local localVars") where \/; Fit deo 


Ayr Ayn 
pre Vj age \ Ree dian) 


eff 
: Ayr Ayr 
if Psa desus then PROG ras desug 
elseif ... 
fi 


_ Ayr 
=> ensuring 1, desug) 


Ayr 
int,t; ,desug 


out,t; ,desug 


ensuring /\; bess 
internal 7(vars4"; local local Vars4") where VP. 


Analogous to output. 


Figure 4.5: Intermediate form of a desugared primitive automaton, with canonical action parame- 
ters and with all transition definitions for each kind of an action combined into a single transition 
definition 
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automaton Watch(T:type, what:Set[T]) 
signature 
input overflow(x:T, s:Set[T]) where x € what 
output found(x:T) where x € what 
states seen:Array[T,Bool] := constant (false) 
transitions 
input overflow(x, s; local s2:Set[T]) where s = s2 U {x} V A(x € s) 


eff if s = s2 U {x} then seen[x] := true 
elseif =(x € s) then seen[x] := false 
fi 


output found(x) 
pre seen[x] 


Figure 4.6: Improved intermediate desugaring of the sample automaton Watch, obtained from the 
intermediate desugaring in Figure [4.4] by combining the transition definitions for overflow 


among the sequences local Varsiiina 1, desig: One might think that a correctly combined transition 
definition might need distinct local variables to store the values of the duplicate local variable appro- 
priate to each contributing transition definition. However, for each assignment of values to vars4* 
only one contributing transition definition can be defined for any assignment of values to its local 
variables. Therefore, there is at most one “useful” initial value for each local variable. Similarly, 
at most one contributing eff clause can make assignments to its local variables. Hence, duplicate 
declarations of local variables have no effect on the combined transition definition. Accordingly, we 
define localVars4™ to be the sequence of variables obtained by removing any duplicates from the 
concatenation of all sequences local Varsie dacdleaiig 

In combining the various clauses of the contributing transitions, we use the where clauses of 
the contributing transitions as guards to select the correct case to use. The four clauses of the 
combined transition are combined as follows: 


e The combined where clause is the disjunction of the where clauses from all the contributing 
transition definitions. 


e For output and internal transition definitions, the combined pre clause checks that one set of 
parameters fulfills both the where and pre clauses of some contributing transition definition. 


e The combined eff clause is a single if...then...elseif...fi statement in which the contribut- 
ing eff clause is guarded by the associated where clause. 


e Similarly, the combined ensuring clause asserts the appropriate contributing ensuring clause 


when the associated where clause is true. Note that since Po eae is defined on the initial 
vB) 


A F : 3 
values of local Vars;,;", t,,desug? 28Signments made to local variables in the eff clause have no 
effect on which ensuring clause is asserted. 


Example 4.3 Consider the desugared and canonicalized automaton Watch shown in Figure 
The only action with multiple transition definitions is the overflow input action. Following the 
above recipe, they are combined into the one equivalent action shown in Figure 

4.4 Combining aggregate sorts and expanding variable references 

Section 8.2] described aggregate sorts that are automatically defined for the state and local variables 
of an automaton A (i.e., States[A, types4] and Locals[A, types“, kind, x, t;]). Desugaring alters the 
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automaton A(types“, vars“) 


states state Vars“4 := initVals4 initially on (P2 3s) 


transitions 
kind 2(vars“:7; local localVars“") where pee 
’ kind,comb,t, 
A Ayr Ayr 
Oo | Ckind pre Prejing 


eff Prog“, ensuri ingi™ 
Tog}, ensuring ensuring,” , 


Figure 4.7: Final form of a desugared primitive automaton, with canonical action parameters, with 
all transition definitions for each kind of an action combined into a single transition definition, and 
with all variable references expanded. 


automaton A and, consequently, can alter these aggregate sorts. In particular, as discussed in 
Section combining multiple transition definitions for a particular action 7 in automaton A 
involves combining the local variables that appear in each transition into a single sequence. We 
collect together all the local variables for each action 7 of an automaton A into a single sequence 
of variables localVars“7, which is the concatenation (with duplicates removed) of the all sequences 
local Vars A : 

As a result, the aggregate sort for local variables also changes. Notationally, the kind and case 
labels t; are dropped from the aggregate local sort name Locals[A, types“, kind, nr, t;]. We define a 
new sort Locals[A, types“, 7] for the combined transition definition to be a tuple with selection oper- 
ators that are named, typed, and have values in accordance with the local variables in local Vars4. 
That is, the set of identifiers for the selection operators on the sort Locals[A, types“, 7] is the union 
of the sets of identifiers for the selection operators on the sorts Locals[A, types“, kind, 1, t;]. We 
change the sorts of the aggregate local and post-local variables A and A’ to this new sort. This has 
the effect of collapsing multiple aggregate local and post-local variables each defined in the scope 
of one transition into a single local and post-local variable defined in all transitions for a given 
action["). 

Formally, for each transition definition t; for a given kind of an action 7 in A, we define a 
resorting! that maps the aggregate local sort Locals|A, types“, kind, nr, t;] to the new aggregate local 
sort Locals|A, types“, m|, and we apply that resorting to the transition definition before performing 
the combining step. As a result, each variable A:Locals[A, types“, kind, 1, t;] is mapped to a variable 
A:Locals|A, types“, rr]. Thus, local variable references using the notation A.v form remain well 
defined and the resorting does not change the text of the transition definition. After combining, 
the sorts Locals[A, types“, kind, n, t;] may be ignored. 

In addition to introducing notations for aggregate local sorts, Section also introduced no- 
tations for aggregate state sorts. These notations provided an additional, and potentially less 
ambiguous, way of referencing the values of local and state variables. We now desugar simple 
references to local and state variables to use the notations for aggregate local and state variables. 


™To avoid complications that arise when new fields are added to an aggregate local tuple during the combining of 
local variables across transitions, we should disallow use of the constructor [__,...] for aggregate local sorts. 
See Section [9] for a formal definition of resortings, which map sorts to sorts. 
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Formally, we define a substitution!®|a4 to map state and post-state variables to terms. If x is a 
state variable or a post-state variable (i.e., 2 € stateVars4 or x € postVars“), then o4(x)) = A.x, 
where A has sort States[A, types4] and the operator __.x has signature States[A, types4] — T, 
where T is the sort of x. 

Similarly, for each transition definition a of type kind, we define a substitution oo to map 
local and post-local variables to terms. If x is a local or post-local variable (i.e., x € local Vars47 
or x € localPost Varssirr), then out (x) = A.x, where A has sort Locals[A, types“, kind, x], and the 
operator __.« has signature Locals|A, types“, kind, | — T, where T is the sort of x. 

Figure shows the final form of a desugared primitive automaton with canonical action 
parameters and local variables and with all transition definitions for each kind of an action combined 
into a single transition definition, and with all variable references expanded. In that figure, we 
indicate the syntactic forms that result from the combining step by use of the comb subscript. 
Figure [4.8] shows the result of applying these substitutions to the sample primitive automata. 


4.5 Restrictions on the form of desugared automaton definitions 


After the definition of a primitive automaton A has been desugared as described in Sections 4.4} 
it has the following properties. 


e No const parameters appear in the signature of A. 


e Each appearance of an action 7 in the signature of A is parameterized by the canonical action 
parameters vars“:7 of m in A. 


e Each transition definition of an action 7 is parameterized by the canonical action parameters 
vars4™ of 7 in A; i.e., every parameter is a simple reference to a variable in vars4. 


e Each action name has at most one transition definition of each kind. 


e Each reference to a state variable x of A, other than in the list of state variables in the states 
statement, has been replaced by the term A.z. 


e Each reference to a post-state variable x’ of A has been replaced by the term A’.z. 


e Each reference to a local variable x in a transition of A, other than in the local clause of that 
transition definition, has been replaced by the term A.z. 


e Each reference to a post-local variable x’ in a transition of A has been replaced by the term 
Al.x. 
4.6 Semantic proof obligations, revisited 


We are now ready to formalize the semantic proof obligations for primitive automata introduced 
in Section [3.4] Previously, we said that for each action named 7 and each sequence of parameters 
values: 


A A Ayr : 
1. At most one of Pj", P57;, and P;” is true. 


Ayr : Ayr + 
2. If P,, , is true, at least one Prhind,t is true. 


6 See Section [9] for a formal definition of substitutions, which map variables to terms. 
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automaton Channel (Node, Msg:type, i, j:Node) 


signature 
input send(n1i, n2:Node, m:Msg) where ni = i A n2 = j 
output receive(ni, n2:Node, m:Msg) where ni = i A n2 = j 
states contents:Set[Msg] := {} 
transitions 
input send(n1, n2, m) where ni = i A n2 = j 
eff Channel.contents := insert(m, Channel.contents) 
output receive(ni, n2, m) where ni = i A n2 = j 
pre m € Channel.contents 
eff Channel.contents := delete(m, Channel.contents) 


automaton P(n:Int) 


signature 
input receive(il, i2, x:Int) where it = n-1 A i2=n 
output send(iil, i2, x:Int) where il =n A i2 = n+l, 
overflow(il:Int, s:Set[{Int]) where il =n 
states 
val:Int := 0, 
toSend:Set[Int] := {} 
transitions 
input receive(il, i2, x) where it = n-1 A i2=n 
eff if P.val = 0 then P.val := x 
elseif x < P.val then 
P.toSend := insert(P.val, P.toSend); 
P.val := x 
elseif P.val < x then 
P.toSend := insert(x, P.toSend) 
fi 
output send(il, i2, x) where i1 =n A i2 = n+l 
pre x € P.toSend 
eff P.toSend := delete(x, P.toSend) 
output overflow(i1t, s; local t:Set[Int]) where il =n 
pre s = P.toSend A n < size(s) A P.t Cs 
eff P.toSend := P.t 


automaton Watch(T:type, what:Set[T]) 
signature 
input overflow(x:T, s:Set[T]) where x € what 
output found(x:T) where x € what 
states seen:Array[T,Bool] := constant (false) 
transitions 
input overflow(x, s; local s2:Set[T]) 
where s = Watch.s2 U {x} V A(x © s) 


eff 
if s = Watch.s2 U {x} then Watch.seen[x] := true 
elseif =(x € s) then Watch.seen[x] := false 
fi 


output found(x) 
pre Watch.seen[x] 


Figure 4.8: Sample desugared automata Channel, P, and Watch, obtained from the intermediate 
desugarings in Figures and [4.6] by desugaring references to state and local variables 


29 


Ayr : Ayr . 
3. If P;,, is true, at most one Pas is true 


We explicitly did not define the phrase “sequence of parameters values” because these predicates 


may be stated in terms of different variables. In other words, vars‘ may be different from vars 


and varsa” 4,- oumilarly, varssy, may be different from ee to, However, after desugaring and 
canonicalizing (but before combining), we have predicates that are semantically equivalent to those 
in the original automaton, but defined over a common set of free variables. That is, all the free 


view e Ayr Ayr A 
variables of all the predicates Ca? pradesue) and O hind Pena levy) are among vars” and 
Ayr 


Vars 


The alert reader will realize that Tables[3.1]and [e-aptist local Vars* . dj; Among the variables that 


may occur freely in gens 7 and Pad. htiesag and might therefore conclude that the aforementioned 
predicates are not “defined over a common set of free variables”. However, as noted Section|3.2| a 
transition 7 is defined only for values of its parameters that, together with some choice of initial 
values for its local variables, satisfy the where clause of the transition definition. Thus, for the 
purposes of formalizing the semantic proof obligations for renee definitions, local variables 


should be existentially bound, not free in where clauses, that is, Po sjcdeduy should be preceded 


by local Varsyr) 4, 

The semantic proof obligations we introduced in Section [3.4] can be stated precisely as follows. 
We require that for each action name 7, all values of vars, and all values of vars4, the following 
statements must be provable from the axioms provided by IOA’s built-in types, by the theories 
associated with the type definitions and the axioms in the IOA specification that contains the 
automaton definition, and by the theories associated with the assumes clause of that definition. 


A, A, A, 
von (en Ces) \ o BPE issu) } (4.1) 
A, A, A, 
v4 (ee, aa) \ Ta ea) ’ (4.2) 
A, A, A, 
von (eo ae) \ Ee Pica) ) (4.3) 
J oir i. Vs localVars3™, of", (pAt ), and (4.4) 
kind\” kind,desug nd: tj ‘ kind,t;\~ kind,t;,desug/? . 
Ayr Ayr 
v Crna! kena yinstig) a (4.5) 
5 A, A, A, 5 Ayr Ayr Ayr 
7 (BlocalVarsii", O hind, t; ( i tesien) /\ local Vars yin d.t, Trina aC onan) ’ 


when 7 # k. 
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5 Definitions for composite automata 


This section introduces notations and semantic checks for composite IOA automata. Section 
describes the syntactic structures that may appear in an IOA description of a composite I/O 
automaton. Section describes notations for the state variables of a composite automaton. 
When component automata have type parameters, the sorts of these state variables are obtained 
by mapping the formal type parameters of the component automata to the actual parameters used 
to instantiate those components in the composition. Finally, Sections and describe the 
conditions that descriptions of composite automata must satisfy to be semantically valid. 


5.1 Syntax 


As for primitive automata, we introduce a labeling of the syntactic elements of composite IOA 
programs in order to facilitate describing their syntactic manipulation. Figure indicates a 
particular labeling of the expressions that can appear in the IOA definition of a composite I/O 
automaton. Again, we have selected the granularity of this labeling to expose just those elements 
of composite IOA programs that are needed in Section |7| to describe the expansion of composite 
automata into primitive form. 


automaton D(types”, vars”) 
assumes Assumptions 
components 
Ci[vars?:%] : Ay(actualTypes?*“, actuals?“!) where P?:@, 
ee 
C,,[vars?>Or] : Ay (actualTypes?’, actuals?) where P?»Cn 
hidden 
Ty (params) in! ) where H oie : 
- 


D D 
Tm(params 72") where 7." 


em 


invariant of D: Inv?; ... InvP 


Figure 5.1: General form of a composite automaton 


In Figure [5.1] parameterized components named C,...,C, are based on instantiations of au- 
tomata named Aj,...,An. The formal parameters of component C; are vars?:“, and the ac- 


tual parameters of automaton A; consist of a sequence actualTypes?’“ of sorts and a sequence 


actuals?’“ of terms. IOA permits the specification of C; to be abbreviated by deleting the colon 
and the following expression when C; and A; are named by the same identifier, actualTypes?’~ 
is empty, and actuals?’ = vars?» (e.g., see component P in Example 2.4). In the specification 


Tp sp 


: : Ditty. 
of hidden actions, params)’ is a sequence of terms, analogous to params,,,,,, and we define 


€p 
D, ; ‘ D, . 
vars ee to be the set of variables that occur freely in params hidey but are not in vars?. Each 
P 


invariant of D is stated as a predicate Inv. 
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SYNTACTIC STRUCTURE | FREE VARIABLES 
actuals? >“ vars? , vars?» 
PPG vars?, vars? % 
Dry D Dry 
Anide, vars”, VATS pide, 
D,tp D D,tp 
params nige, vars”, VATS ride, 

Inv? vars”, state Vars? 


Table 5.1: Variables that can occur freely in terms in the definition of a composite automaton. 
Variables listed on the right may occur freely in the syntactic structure listed to their left. 


Example [2.4] conforms to this general form, as follows. 

e The first component of Sys is named C. Its parameters, vars SC. are (n:Int), and it is based 
on the automaton Channel, for which it supplies the actual parameters actual Types®¥*:© a 
(Int, Int) and actualsSY*° = (n, n+1). 


e The second component of Sys is named P. It has the same parameters as C. By the conventions 
for abbreviating component descriptions, it is based on the automaton of the same name, for 
which it supplies the actual parameters actuals°¥8? — (n); in this case, actual Types®¥*-P is 
empty (as required to use this abbreviated form). 


e The third component of Sys, named W, has no parameters. It is based on the automaton Watch, 
for which it supplies the actual parameters actualTypes°¥S" = (Int) and actuals®¥8“ 


(between (1 ,nProcesses) i. 


e The send actions that Sys inherits from P[nProcesses] are hidden as internal actions in Sys. 


Sys, d : : ‘ 
The parameters params) vi. sene = (nProcesses, nProcessesti,m) in the single clause in the 
P : ; ‘ 7 Sys,send Sys,send. 
hidden statement involve a single free variable in vars rae is = (m:Int), and A, bs is 


true. 


e The predicate 
Vom:Int V n:Int (1 <mAm <n An < nProcesses 
=> P[m].val < P[n].val V P[n].val = 0) 


is invariant Inv§ of Sys. 


5.2 State variables of composite automata 


The definition of a composite automaton in IOA does not mention the automaton’s state variables 
explicitly. Rather, its components statement implicitly introduces a single state variable for each 
component. We first describe the notations IOA provides for state variables associated with com- 
ponent automata that have no type parameters. Then we describe how these notations extend to 
state variables associated with component automata that have type parameters. Our goal is to 
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provide a precise explanation of notations for state variables such as P[m].val, which appears in 
the invariant for the sample composite automaton Sys. 

As for primitive automata (see Section [3.2), we automatically define a sort States[D, types? | 
representing the aggregate states of a composite automaton D, and we also define aggregate state 
and post-state variables D and D’ of sort States[D,types?]. Furthermore, we treat the sort 
States[D, types”] in the same fashion as for primitive automata, namely, as a tuple of state vari- 
ables: we define the aggregate state of a composite automaton D to be a tuple containing a state 
variable for each component automaton, and we use the names of the components (i.e., C1,...,Cn) 
as the names of these state variables and of the corresponding selectors (i.e., __.Ci,...,-_-Cn) of 
States[D, types”). 


Sees 


State variables for components with no type parameters 


Defining the sort of the state variable C; is simplest when the component C; does not have pa- 
rameters and when the automaton A; on which C; is based does not have type parameters. For 
each such component C;, the state variable C; of D has sort States|A;], and the selector __.C; has 
signature States[D, types?] — States[Ai]. 

When the component C; has parameters, but A; still does not have type parameters, the 
situation is slightly more complicated, because the composite automaton D may contain multiple 
instances of A;. For example, the composite automaton Sys contains nProcesses instances of the 
component automaton P, each with its own state variables val and toSend. These instances are 
parameterized by a single integer n and are distinguished by the component names P[1], ..., 
P[nProcesses]. 

For each parameterized component C;, the corresponding state variable C; does not refer to 
the aggregate state of a single instance of A;. Rather, it refers to a map from the values of the 
parameters vars?:@ of C; to the aggregate states of A;. That is, the state variable C; has sort 
Map[types?*°:, States[A;]], where types?* is the sequence of sorts of the variables in vars?*“. The 
selection operator __.C; has signature States|D, types?] — Map[types?’©, States[Aj]). 

For example, the state variable P of Sys has sort Map[Int ,States[P]]. Hence, P[n] is a legitimate 
term with sort States [P], and the term P[n] .val has sort Int. Likewise, the selection operator __.P 
has signature States[Sys] — Map[Int,States[P]], and Sys.P[n] .val is an alternative notation for 
the state variable val that Sys inherits from component P[n]. 


Resortings for automata with type parameters 


Defining the sort of the state variable C; is more complicated when A; has type parameters. Since 
the semantics for IOA are defined using multisorted, first-order logic, we cannot quantify over sorts 
or use sorts as component indices. Instead, different instances of A;, corresponding to different 
actual types, must be described in separate clauses in the components statement, where they 
are further distinguished by different component names. As a result, there can be only finitely 
many differently typed instantiations of A;, even though altogether there may be infinitely many 
instances of A; that are distinguished by the values of their non-type parameters. For example, 
a composite automaton might contain channel components that transmit finitely many different 
types of messages, but there may be infinitely many instances of such a component that transmits 
a given type of message. 

When a component C; is based on an automaton A; parameterized by the sorts types“, we 
define a resorting p; (which we write as p“ in contexts, such as p", where it is more convenient to 
use the name of the component rather than its position in the list of all components) that maps 
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Watch _ (T) Sys ,W _ ( 


types“: to actualTypes?’™. For example, pu maps types to actualTypes Int), 
and p° maps types°b@mnel — (Node, Msg) to actualTypes®¥**° = (Int, Int). 

As described in Section|9} there is a natural way to extend the resorting p; to map arbitrary sorts 
involving the formal type parameters in the defining automaton A; to sorts involving the correspond- 
ing actual types that the component C; supplies for A;. For example, this extension maps the auto- 
matically defined sort States[A;, types4‘] for the state of A; to the sort States[A;, actual Types?’ | 
for the state of the instances of A; corresponding to the component cr] 

The resorting p; also extends naturally to map operators with signatures involving the formal 
type parameters in the defining automaton A; to operators with signatures involving the corre- 


sponding actual types that the component C; supplies for A;. Thus, for example, p° maps 
States[Channel,Node,Msg] = tuple of contents: Set[Msg] 


to 
States[Channel,Int,Int] = tuple of contents: Set[Int] 


and it maps the signature of the selection operator __.contents from States [Channel ,Node,Msg] — 
Set [Msg] to States[Channel,Int,Int] — Set[Int]. 


State variables for components with type parameters 


When A; has type parameters, we employ a resorting of its aggregate state sort to define the 
sort of the state variable C; of D. In the simple case when the component C; does not have any 
parameters, the state variable C; has sort States|Aj, actualTypes? Ci) and the selection operator 
__.C; has signature States[D, types?] — States[A;, actualTypes?™], 

For example, the state variable W of Sys has sort States [Watch,Int], the term W.seen has sort 
Array [Int ,Bool], the selection operator __.W has signature States[Sys] —> States[Watch, Int], 
and Sys.Watch.seen is an alternative notation for the state variable seen that Sys inherits from 
component W. 

In the case when the component C; has parameters (and the automaton A; has type parame- 
ters), the state variable C; has sort Map (types? , States[ Aj, actualTypes?’“]], where types?*@ is 
the sequence of sorts of the variables in vars?:©, and the selection operator __.C; has signature 
States[D, types?] — Map[types?>:, States[.A;, actual Types?’@']], 

For example, the state variable C of Sys has sort Map[Int ,States[Channel,Int,Int]], the term 
C[n] has sort States[Channel[Int,Int], the term C[n].contents has sort Set [Int], the selection 
operator __.C has signature States[Sys] — Map[Int,States[Channel,Int,Int], and C[n].contents 
is an alternative notation for the state variable contents that Sys inherits from component C[n]. 


5.3. Static semantic checks 


The following must be true for an IOA program to represent a valid composite I/O automaton and 
can be checked statically. These checks are currently performed by ioaCheck, the IOA parser and 
static-semantic checker. 


Vv No sort appears more than once in types? : 


Vv Each component name (i.e., Cj) occurs at most once. 


D D,C; 


Vv The sequences vars” and vars of variables contain no duplicates; furthermore, no variable 
appears in both vars? and vars?’ for any value of i. 


17 Although Aj, types“, Ci, and actualTypes”’% appear as subsorts of a sort constructor States[__,...], IOA 
assigns no semantics to these sorts. Syntactically, however, they are treated in the same fashion as other sorts; in 
particular, the resorting p; replaces types“ by actualTypes”’. 
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¥ Each component automaton is supplied with the appropriate number of actual types, that is, 
actualTypes?’“ has the same length as types“’. 


v For every operator f in a theory specified in the assumes clause of the automaton A;, a 
corresponding operator p;(f) must be introduced by a type definition or axioms clause in 
the IOA specification that contains the definition of D, by a theory specified in the assumes 
clause of D, or by a built-in datatype of IOA. 


¥ Each component automaton is supplied with the appropriate number and sorts of its other 
actual parameters, that is, actuals?’° has the same length as vars“: and the same sorts as 


pi(vars“*). 


¥ Each component automaton is supplied with actual types that do not reduce the number of 
distinct state variables. That is, all selectors of States[Aj;, actual Types? se are distinct. 


Vv All occurrences of an action name 7 in all component automata have the same number and 
sorts of parameters; that is, if 7 is an action name in both A; and Aj, then vars“ has the 
4y™ and p;(vars4%7) ADT), 


same length as vars has the same sort as p;(vars 


Vv Each action name in a hidden statement must be an action name in some component au- 
tomaton. 


Vv All occurrences of an action name 7 in a hidden statement have the same number and sorts 
of parameters as the occurrences of the action name 7 in the component automata; that is, 
if 7 is an action name in some A; and 7 = 7,» for the hidden clause p, then vars4i™ has the 

An) 


Dyn, Dy 
same length as params, , and p;(vars has the same sorts as params,,,, 2 : 


¥ Any variable that occurs freely in a term used as a parameter or predicate, in the definition 
of a composite automaton must satisfy the restrictions imposed by Table [5.1] 
5.4 Semantic proof obligations 


The following must also be true for an IOA program to represent a valid I/O automaton. Except in 
special cases, these conditions cannot be checked automatically, because they may require nontrivial 
proofs (or even be undecidable); hence static semantic checkers must translate all but the simplest 
of them into proof obligations for an automated proof assistant. 


¥ Only output actions may be hidden. 
¥ The components of a composite automaton must have disjoint sets of output actions. 


Vv The set of internal actions for any component must be disjoint from the set of all actions of 
every other component. 


We will express these these proof obligations in first-order logic in Section [7.4] using syntactic 
forms we define earlier in Section 


'8An implementation of these checks might reduce the number of errors reported by first confirming that the 
composition contains no duplicate instances of any component automaton that contains internal or output actions. 
Any such duplication would necessarily cause violations of the latter two checks. 
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6 Expanding component automata 


Before we can describe the contribution of a component C; of a composite automaton D to the 
expansion of D into a primitive automaton DExpanded, we must take four preparatory steps. The 
result is a component that represents the instantiation of automaton A; on which C; is based using 
the actual parameters supplied by the component and whose variables have been translated into a 
unified name space used for DExpanded. 


The first step is to desugar the definition of each component automaton A; as described in 
Section |4| In the discussion below, we refer to this desugared version of A; as A; and assume that 
it satisfies the restrictions listed in Section [4.5] The second step, shown in Section [6.1] is to replace, 
throughout the entire definition of the automaton Ai, the formal type parameters types“ of A; 
by the actual types actualTypes?’*“ supplied by the component C;. The third step is to replace 
the formal automaton (non-type) parameters vars“: by the actual parameters actuals?’ supplied 
by the component C;. The fourth step is to translate the aggregate state variables, aggregate 
local variables, and action parameters from the name space of A; into a unified name space for 
DExpanded. (It is not necessary to translate individual state and local variables, because references 
to them have been eliminated by the desugaring described in Section [4.4]) Sections describes 
how we choose canonical action parameters for the unified name space. Section [6.3] describes the 
substitution we use to perform both this translation and the instantiation of actual automaton 
parameters for the previous step. Table [6.8] summarizes the notation, figures, and examples we use 
to present these stages. 

Section describes the result of applying these replacements and translations to individual 
component automata. It sets the stage Section [7] which describes how to combine the expanded 
components into a description of DExpanded by developing explicit representations for its signature 
and transition definitions. 


6.1 Resorting component automata 


We produce a definition of the instances of A; whose sorts correspond to those of the oe Ci 
by replacing the formal type parameters types“: of A; with the actual types actualTypes?’™ sup- 
plied by the ee C;. This replacement is accomplished by applying the resorting p;, defined 
in Section |5.2|to the entire definition of the automaton A;. The precise definition of resortings and 
a full deserintion of how resortings are extended to perform this replacement throughout the entire 
definition of the automaton A; are given in Section |9| We denote the resulting definition by pi Aj. 


Example 6.1 Tables show how the resortings pe and p", induced by the components 
statement of the sample suornaon Sys in Example map the sorts, van avlee: and operators 
of the component automatal!9] The resorted components p°Channel and p"Watch of the composite 
automaton Sys are oe in Figure [6.1 [6.1] Since the component automaton P of Sys does not have 
any type parameters, pr is the identity, and the resorted component prP i is the same as shown in 


Figure 


'The table shows only the non-identity mappings of sorts, variables, and operators. Sorts, variables, and operators 
that appear in the sample automata, but are not shown in the table, are mapped to themselves. 
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RESORTING DOMAIN RANGE 
Node Int 
ie Msg Int 
Set [Msg] Set [Int] 
States [Channel , Node, Msg] States (Channel, Int, Int] 
T Int 
Set [T] Set [Int] 
Me Array [T, Bool] Array [Int ,Boo1] 
States [Watch,T] States [Watch, Int] 
Locals[Watch,T,overflow] | Locals[Watch,Int,overflow] 


Table 6.1: Mappings of sorts by resortings in the composite automaton Sys. Resortings listed on 


the left map domain sorts to their right to the range sorts on their far right. 


RESORTING | DOMAIN RANGE 
i:Node i:Int 
j:Node j:Int 
C contents: Set [Msg] contents: Set [Int] 
ni:Node ni:Int 
n2:Node n2:Int 
m:Msg m:Int 
what :Set [T] what :Set [Int] 
seen:Array[T,Bool] | seen:Array[Int,Bool] 
ol x:T x:Int 
x:T x:Int 
s:Set([T] s:Set [Int] 
s2:Set[T] s2:Set [Int] 


Table 6.2: Mappings of variables by resortings in the composite automaton Sys. Resortings listed 
on the left map domain variables to their right to the range variables on their far right. 
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RESORTING OPERATOR ORIGINAL AND NEW SIGNATURES 


Node ,Node—Bool 


Int , Int—Bool 


Msg,Msg—Bool 


Pp Int , Int—Bool 


—Set [Msg] 


—Set [Int] 


Msg, Set [Msg] Bool 


Int ,Set [Int]—Bool 


Msg, Set [Msg] —Set [Msg] 
insert 


Int ,Set [Int] —Set [Int] 


Msg,Set [Msg] —Set [Msg] 
delete a . ? 


Int ,Set [Int] —Set [Int] 


States [Channel , Node ,Msg]—Set [Msg] 
__.contents 


States [Channel, Int , Int] —Set [Int] 


T—Bool 
[__] 


Int—Bool 


T—Set [T] 
ao pad 


p Int—Set [Int] 


Set [T] ,Set [T] —Bool 


Set [Int] ,Set [Int]—Bool 


T,Set [T] Bool 


Int ,Set [Int] —Bool 


Set [T] ,Set [T] —~Set[T] 


Set [Int] ,Set [Int]—Set [Int] 


States [Watch,T] Array [T, Bool] 
_..seen 


States [Watch, Int] —Array [Int , Bool] 


Locals [Watch,T, overflow] —Set[T] 


Locals [Watch, Int, overflow] —Set [Int] 


Table 6.3: Mappings of operators by resortings in the composite automaton Sys. Resortings listed 
on the left map domain operators to their right to the range operators on their far right. 
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% Resorting of Channel for component C of Sys 
automaton Channel (Node, Msg:type, i, j:Int) 
signature 
input send(n1, n2:Int, m:Int) where nit =i A n2 = j 


output receive(ni, n2:Int, m:Int) where ni = i A n2 = j 


states contents:Set[Int] := {} 
transitions 
input send(n1, n2, m) where ni =i A n2 = j 
eff Channel.contents := insert(m, Channel.contents) 
output receive(ni, n2, m) where ni =i A n2 = j 
pre m € Channel.contents 
eff Channel.contents := delete(m, Channel.contents) 


% Resorting of Watch for component W of Sys 
automaton Watch(T:Type, what:Set[Int]) 
signature 
input overflow(x:Int, s:Set[Int]) where x € what 
output found(x:Int) where x € what 
states seen:Array[Int,Bool] := constant (false) 
transitions 
input overflow(x, s; local s2:Set[Int]) 
where s = Watch.s2 U {x} V A(x € s) 


eff if s = Watch.s2 U {x} then Watch.seen[x] := true 
elseif =(x € s) then Watch.seen[x] := false 
fi 


output found(x) 
pre Watch.seen[x] 


Figure 6.1: Sample component automata Channel and Watch, obtained by resorting the desugared 


automata shown in Figure 
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6.2 Introducing canonical names for parameters 


For each action name 7 in some component C; of D, we pick a sequence vars? of variables to be 
the canonical action parameters of 7 in D. Since the static checks ensure the number and sorts of 
variables in p;(vars4%) are the same for all components C;, we take vars?” to be p;(vars4%) for 
the smallest 7 such that 7 is the name of an action in C; and this choice does not cause variables 
to clash. In particular, no variable in vars?*7 should be a parameter of D (i.e., vars?*™ and vars? 
should be disjoint) nor of any component C; (i.e., vars? and vars?» should be disjoint) P>| 

If vars?** cannot be defined in this fashion (without causing variables to clash), then we let 
t be the smallest integer such that 7 is the name of an action in C;, and we take vars?*™ to be 
Aur) with any clashing variables replaced by fresh variables, that is, with variables not in 
D,Ci 


pi(vars 
vars? nor any vars 


6.3. Substitutions 


For each component C; of a composite automaton D, we define a substitution o; (which we write as 


o@ in contexts, such as o”, where it is more convenient to use the name of the component rather 
than its position in the list of all components) to map the non-type parameters varshiti = pi(vars“*) 
D, C; 


of the component automaton pi A; to the corresponding actual parameters actuals and to map 
the aggregate state and post-state variables of pA; to the appropriate state components in the 
composite automaton. For each action 7 of Cj, we also define a substitution o;,, to be the same as 
o;, except that it also maps the canonical action parameters vars? = pi(vars“) of pi Aj to the 
corresponding canonical action parameters vars?7 in D, and that it maps the aggregate local and 
post-local variables for transition definitions in pi Aj to the appropriate local and post-local values 
in the composite automaton. 
These substitutions?"| are summarized in Table [6.4] and defined by rules [1}{9] below. 


Aj, 


1. If z is a non-type parameter of A; (ie., x € varsPiAi) then ojp;(x) is the corresponding 
element of actuals?>™. 


2. If C; has no parameters and z is the variable A; of sort States[A;, actualTypes?’™] representing 
the aggregate states of p;A;, then o;(x) is the state variable for the component C; of D, which 


has the same sort as A;. 


3. If C; has parameters and z is the variable A; of sort States[A;, actualTypes”’“], then o;(2) 
is the term C;[vars?’“], where C; is the state variable for the component C; of D, which has 
sort Map[types?>“, States[ Aj, actualTypes?’“]]. 

4. If C; has no parameters and z is the variable Aj of sort States[A;, actual Types”) representing 
the aggregate post-states of p;A;, then o;(«) is the post-state variable C/ for the component 
Ci of D. 

5. If C; has parameters and 2 is the variable A/ of sort States[A;, actualTypes?’™], then o;(a) is 

the term C; [vars?:%], where C* is the post-state variable for the component C; of D, which 

has sort Map[types?’“, States[A;, actualTypes?’“]. 


20Tt is not necessary to avoid clashes with the state variables p;(state Vars“‘) or post-state variables p; (post Vars“:) 
of C;, because desugaring has replaced references to such variables x by terms C}.a. 

21 See Section|9}for a precise definition of substitutions, which ensures that they do not capture local, for, choose, 
or quantified variables. 
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SUBSTITUTION | DOMAIN RANGE 
varsPiAi actuals?» 

0; A;:States[A;, actualTypes?@ C; 
A;:States[A;, actualTypes?>% C;[vars?] 
varshiAi actuals?» 
A;:States[A;, actualTypes?>% C; 
Aj: States[A;, actualTypes?:% C;[vars?] 
Al: States[A;, actualTypes?’~ Cc 
Al: States[A;, actualTypes?:~ Ci[vars?@) 

Cm 7 

varsPiAis™ vars? ™ 

A;:Locals[A;, actualTypes?’%, x] | C; 
Al: Locals[A;, actual Types”, x] | Ci 
A;:Locals[A;, actualTypes?’“, x] | C;[vars?>@] 
Al: Locals[A;, actual Types“, x] | Ci[vars?:@] 


Table 6.4: Substitutions used in canonicalizing component automata. Substitutions listed on the 
left map variables in the domains to their right to range variables according to the listed rules. 


6. There is no rule [6] 


7. If x is a canonical action parameter (i.e., 2 € vars47) 


element of vars)". 


, then o;,,pi(x) is the corresponding 


8. If C; has no parameters and x is the variable A; of sort Locals{A;, actualTypes?’“"] (or the 
variable A’ of the same sort) representing the aggregate local (or post-local) variables for a 
transition definition, then o;(x) is the local variable C; (or the post-local variable C/) for the 
transition definition in D, which has the same sort as Aj. 


9. If C; has parameters and « is the variable A; of sort Locals[A;, actualTypes?’*@"] (or the 
variable A’ of the same sort), then o;(x) is the term C;[vars?’°] (or the term C![vars?>@]), 
where C; and C/ are the aggregate local and post-local variables in D, which have sort 
Map types?» , Locals[ Aj, actualTypes?’™, ml. 


6.4 Canonical component automata 


For each component C; of D, we obtain a canonical automaton definition C; for that component 
by applying p; and then o; to the desugared definition Aj of Aj. Figure 6.2] shows the general form 
for such canonical component automata. 

In the list of parameters for C;, the type parameters types? of D replace the type parameters 
types“: of A;, and the variables vars? and vars?:“ that parameterize D and its component C; 
replace the individual parameters vars“: of A;. The body of the automaton definition for C; is 


obtained by applying the resorting p; to the body of the automaton definition for A;, thereby 
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eliminating all references to the type parameters in types“‘, to obtain a resorted definition for an 
automaton pi A; and then by applying the substitution o; ie wos resorted definition, thereby elim- 
inating all references to the individual parameters in vars4:. We do not SDD a; to state Vars?'*, 
because we wish to preserve the names of the state variables in state Vars“'. No ambiguity arises, 
because the desugaring described in Section |4.4) [4.4] has replaced all references to state variables x in 
the definition of A; with terms of the form A;.z. For each action ™, we also apply o;,, to the where 


clause ppiA i for 7 in the signature of pA; and to the transition definition for 7 in pi Ay. 


Despite the absence of ambiguity, the automaton C; may not pass the static semantic require- 
ments in Section [3.3] that prohibit any clashes between state variables and automaton parameters. 
Furthermore, if C; has non-type parameters, the aggregate state variable for the automaton is a 
map as specified in Section [5.2|rather than a tuple as specified for primitive automata in Section [3.2] 

Table shows the steps taken to expand canonical component automata. The “Original” 
column lists the names for syntactic elements of automata introduced in Section |3} The notation 
given in the “Desugared” column describes the result of desugaring such automata as described in 
Section [4] The elements listed in the the “Resorted” column result from the resorting of desugared 
component automata that Section describes. Syntactic elements listed in the “Expanded” 
column are derived in Section from resorted automata. Finally, names that appear in the 
“Component” column are just synonyms for the values in the previous column. We use these 
simpler synonyms in Section [7 


automaton C;(types”, vars?, vars?) 


signature 


Dyr pei A; (7 


kind n(vars~’") where oj,7(Py;,7°) 


states state Vars?'4' := 0;(init Vals?) initially oi( PRAY) 
transitions 


piAi, Aas) 


™: local local Vars? peidim 


kind (vars where Pring i; 


. 
Oi,n pre Prekind” 


7 Ain pi Ain 
eff Prog i¢@ ensuring ensuring). j 


Figure 6.2: General form of the expansion of the automaton for component C;, obtained from the 
desugared definition A; of the automaton on which C; is based 


Example 6.2 We derive the component automata C, P, and W of the composite automaton Sys by 
applying the substitutions shown in Tables|6.5}{6.7] to the resorted automata p°Channel and p"Watch 
shown in Figure|6.1]and to the canonicalized automaton P shown in Figure|4.8] 4.8| Since the per-action 
substitutions (e.g., c¢*8¢) are always extensions of the per-component substitutions (e.g., o°), 
these tables show only the additional mappings that distinguish the per-action substitutions from 
the per-component substitutions. We also omit from these tables identity mappings. For example, 
we omit from Table |6.6] the identity mapping of i1:Int to itself due to rule|7Jin oP:°verflow, The 
resulting component automata are shown in Figures 
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automaton C(nProcesses:Int, n:Int) 


signature 
input send(n1, n2:Int, m:Int) where ni =n A n2 = n+l 
output receive(ni, n2:Int, m:Int) where ni =n A n2 = ntti 
states contents:Set[Int] := {} 
transitions 
input send(n1, n2, m) where ni = n A n2 = n+l 
eff C[n].contents := insert(m, C[n].contents) 
output receive(ni, n2, m) where ni =n A n2 = ntl 
pre m € C[n].contents 
eff C[n].contents := delete(m, C[n].contents) 


Figure 6.3: Sample instantiated component automaton C, obtained by applying the substitutions 
in Table [6.5] to the resorted automaton Channel in Figure 


SUBSTITUTION | DOMAIN RANGE 


Channel:States[Channel,Int,Int] | C[n] :Map[Int,States[Channel, Int, Int]] 


oO C i:Int n:Int 
j: Int (n+1) :Int 
ooSend No additional substitutions 


goreceive No additional substitutions 


Table 6.5: Substitutions used to derive sample component automaton C. Substitutions listed on 
the left map variables in the domain to their right to variables in the range their far right. 


SUBSTITUTION | DOMAIN RANGE RULE 

oP P: States [P] P[n] :Map[Int ,States[P]] rule 
ii:Int ni:int rule 

geome i2:Int n2:int rule 


x:Int m:int rule 


i1:Int ni:int rule 


gh receive i2:Int n2:int rule 


x:Int m:int rule 


oP,overflow P:Locals[P,overflow] | P[n]:Map[Int,Locals[P,overflow]] | rule 


Table 6.6: Substitutions used to derive sample component automaton P. Substitutions listed on 
the left map variables in the domain to their right to variables in the range their far right. 
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automaton P(nProcesses:Int, n:Int) 


signature 
input receive(ni, n2, m:Int) where ni = n-1 A n2=n 
output send(ni, n2, m:Int) where nil =n A n2 = ntl, 
overflow(il:Int, s:Set[{Int]) where ii =n 
states 
val:Int := 0, 
toSend:Set[Int] := {} 
transitions 
input receive(ni, n2, m) where ni = n-1 A n2=n 
eff if P[n].val = 0 then P[n].val :=m 
elseif m < P[n].val then 
P[n].toSend := insert(P[n].val, P[n].toSend); 
P[n].val :=m 
elseif P[n].val < m then 
P[n].toSend := insert(m, P[n].toSend) 
fi 
output send(ni, n2, m) where ni = n A n2 = n+l 
pre m € P[n].toSend 
eff P[n].toSend := delete(m, P[n].toSend) 
output overflow(iit, s; local t:Set[Int]) where it =n 
pre s = P[n].toSend A n < size(s) A P[n].t Cs 
eff P[n].toSend := P[n].t 


Figure 6.4: Sample instantiated component automaton P, obtained by applying the substitutions 
in Table [6.6] to the automaton P in Figure 


automaton W(nProcesses: Int) 

signature 
input overflow(il:Int, s:Set[Int]) where it € between(1, nProcesses) 
output found(ii:Int) where il € between(1, nProcesses) 

states seen:Array[Int,Bool] := constant (false) 

transitions 
input overflow(il, s; local s2:Set[Int]) 

where s = W.s2 U {il} V 7ACil € s) 


eff if s = W.s2 U {iit} then W.seen[ii] := true 
elseif =(i1 € s) then W.seen[ii] := false 
fi 


output found(il) 
pre W.seen[it] 


Figure 6.5: Sample instantiated component automaton W, obtained by applying the substitutions 
in Table [6.7] to the resorted automaton Watch in Figure 
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SUBSTITUTION | DOMAIN RANGE 


W Watch:States[Watch, Int] W:States (Watch, Int] 
oO 


what :Set [Int] between(1, nProcesses) 


W Watch:Locals[Watch,Int,overflow] | W:Locals[Watch, Int,overflow] 
gW.overflow 


x:Int it:int 


oW,found x:Int i1:Int 


Table 6.7: Substitutions used to derive sample component automaton W. Substitutions listed on 
the left map variables in the domain to their right to variables in the range their far right. 
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Syntactic Element Original Desugared Resorted Expanded Component 

Automaton A A pi A; Oi Pi A C; 

General form Figure 3.1 Figures 4.3, 4.5, 4.7 Figure 6.2 

Automaton parameters types“, vars“ types, pivars4 types? , vars? , vars? 

Action parameters params‘. varsAe™ pivarsim CimpivarsAi™ vars? ™ 

Signature where predicates Po pan ;PAun oimpiP oi po 

State variables state Vars“ pistate Vars* state Vars ~ 

Aggregate variable name Aj C; 

Ageregate state sort States[ Aj, types“ | States[A;, actual Types?’ 

Aggregate local sort Locals|Aj;, types“, kind, m, tj] | Locals[Aj;, types“, 7] Locals| Aj, actualTypes?’™, T| 

Initial state variables values init Vals“ pxinit Vals“ Oi Pi init Vals“ init Vals © 

initially predicate Pee PA: pi PAs, Oi Pi PA: P <i 

Transition parameters Params vars4v™ pivarshim CimpivarsAi™ vars? ™ 

local variables local Varsi7 : local Varsdi™ pi local VarsAi" Ji,npi local Vars Ai localVars i 
ib 

Transition where predicates Pete pee piPper oi PAE, Pay 

Transition pre predicates Pre ay Presi pi Presi oinpiPresi Prec 

Transition eff programs Progisa Prog is" pi Prog Ais oimpiProg iim Progc 

Transition eff predicates ensuring, i ensuring Ai" piensuring di cin piensuring Aim ensuring. 
| 

Channel Figure 2.1 Figure 4.8 Figure 6.1 Figure 6.3 

P Figure 2.2 Figure 4.8 Figure 6.4 

Watch Figure 2.3 Figure 4.8 Figure 6.1 Figure 6.5 


Table 6.8: Stages in expanding components C; of a composite automaton D. 
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7 Expanding composite automata 


In this section, we present the main contribution of this document. We show how to expand a com- 
posite IOA program into an equivalent primitive IOA program. Section [7.1]reviews our assumptions 
about the form of the components of the composite automaton, and Section [7.2] describes a simpli- 
fication of the structure of hidden statements, obtained by combining all clauses for a single action 
into a single clause. 

In Section we define the expansion of the signature of a composite automaton to primitive 
form. Section gives first-order logic formulas for the semantic proof obligations we introduced in 
Section [5.4] These include compatibility requirements for component automata. In Section [7.5] we 
define the expansion of the initially predicate on states of a composite automaton. In Sections 7.6} 
7.9, we define the expansion of the transitions of a composite automaton. 


7.1 Expansion assumptions 


We expand a composite automaton D into primitive form by combining elements of its components 
C1, ..., Cy. We assume each component automaton A; has been desugared to satisfy the restrictions 
in Section | resorted to produce an_automaton pi Aj as described in Section |5.2] and |6.1} and 
neg as described in Section |6.4|to produce an automaton oipiA;y = = Cj. im particular, for 
each component automaton C;, we assume the following. 


e No const parameters appear in the signature. 


e Each appearance of an action 7 in the signature is parameterized by the canonical action 
parameters vars? ™, 


e Each transition definition of an action 7 is parameterized by the canonical action parameters 
Dyr 


vars 
e Each transition definition of an action 7 is further parameterized by the canonical sequence 
Jinx pi local Vars4i™ of local variables for that component. 


e Each action has at most one transition definition of each kind. 


e Every state, post-state, local variable, or post-local variable reference is of the unambiguous 
form C;.2, Ct.x, C;[vars?’“].2, or Cl[vars2 ©}... 


7.2  Desugaring hidden statements of composite automata 


The syntax for composite IOA programs as described in Section [5] provides programmers with flex- 
ibility of expression that can complicate expansion into primitive form. Hence, as with primitive 
automata, it is helpful to consider equivalent composite IOA programs that conform to a more 
limited “desugared” syntax. As discussed later in this section, where clauses of composite au- 
tomaton hidden statements and of component transitions are combined during expansion. Thus, 
hidden statements must be desugared into a form analogous to that of a desugared transition. 
In particular, we desugar composite automata with hidden statements to have the following two 
properties. 


e Each hidden clause for an action 7 is parameterized by the canonical action parameters 
varsP™, 
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e There is at most one hidden clause for each action 7. 


The static checks described in Section [5.3|ensure that the number and sorts of terms in params). 


Dry 


are the same as the number and sorts of variables in vars . If no variable in vars?:7” occurs 


: Dytp /: : Dyr D,tp oe 
freely in params jee (i.e., if vars’?™? and vars hide, are disjoint), then we can desugar the clause 


Dyn D,tp 
Tp(params pize, ) where Aide, 


: : D : . : : 
D7» reintroducing vars;,’,” as existentially quantified variables 
’ hidep 


by replacing params)" den by vars 
in the where clause, and adding conjuncts to the where clause to equate vars?» with the old 
parameters. This results in the desugaring 


Dy 


Dor = Dp Pp Dirty _ D,tp 
») where 4 VAIS rite, Gs A vars’? = paramsiige, ) - 


Tp( vars 


Notice that introducing vars ine as existentially quantified variables is analogous to introducing 


A, 
vars; ae as local variables when desugaring transition parameters, as described in Section [4.1| 


Dir 
If vars?:™” and vars hie, are not disjoint, we define a substitution oe that maps the intersec- 


tion of these two sets to a set of fresh variables, and we desugar the hidden clause as 


Dytp _ =5 


where jo 


D, 
Ta) : 


hide Dir a: hide ppD mp 


VATS pide hidep /\ vars 


Dyr 
Tp(vars params), ae 


We simplify each existentially qualified where clause produced by the above transformations 
by dropping any existential quantifier, such as 4 i:Int in the example, that introduces a variable 
é boo a : : ; : D,rp —_ hide D,tp 

quated to a term, as in i = x in the example, in the conjunction vars’’"? = o,"“°params),;, ep? and 
also by dropping the equating conjunct from that conjunction. We denote the resulting simplifica- 
tion of the where clause by Te coisas 

Following this clause-by-clause canonicalization, we combine all clauses in the hidden statement 
that apply to a single action 7 into one disjunction. This step is analogous to the combining step 


for transition definitions in Section For example, if tp = 7 = 7, then the clauses 


D,tp 
) where La canon 


D,tq 
where Fite, canon 


Tp( vars 


Tq(vars?'™*) 


become the single clause 


Pe) V HPT 


D,tp 
where H, hideg,canon* 


m(vars hidep ,canon 


We denote this combined where clause by H?”. 


7.3 Expanding the signature of composite automata 


In the composite automaton D, actions that are internal to some component are internal actions of 
the composition, actions that are outputs of some component and are not hidden are output actions 
of the composition, and actions that are inputs to some components but outputs to none are input 
actions of the composition. The where clause predicates ie express these facts in the signature 
of the expanded automaton DExpanded. We construct these predicates by defining subformulas, 


D,C;, D, . . : . ais 
Pina ” and Prov seu which describe the actions components contribute to the composition. We 
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automaton DExpanded(types”, vars”) 
signature 


. Dyr Dir 
kind m(vars”’) where P,.'", 


Figure 7.1: General form of the signature in the expansion of a composite automaton 


combine these formulas and the where predicate from any applicable hidden clause (i.e., H?:7), 
to account for the subsumption of input actions by output actions and for hiding output actions. 
The final result consists of the three predicates pe, pom , and Por 

All free variables that appear in these predicates are among the composite automaton parame- 
ters vars? and the canonical action parameters vars?". F igure [7.1] shows the general form of the 
expanded signature. Below, we explain how to construct these predicates. (See Section for an 


example application of the process to composite automaton Sys defined in Example [2.4]) 


Subformulas for actions contributed by a component 


In order for an action kind (vars?) to be defined in D, it must be defined in some component. 


An action is defined in a component C; of D if, given action parameters vars?™ there are component 


parameters vars?’ that satisfy both the component where clause P?:“ and the action where 


clause a for 7 in the signature of C;. Hence we define 
DCiyr i D,C; D,C; Ci 
Po = avers LP WP eal 


which is satisfied by vars?” if and only if (vars?) is an action of type kind in component C; of 
D. 

It is important to note that the type of the action a(vars 
type of 7 in some, or even all, the components contributing the action to the composition. Output 
actions in one instance of one component may subsume inputs in another, and output actions may 
be hidden as internal actions in the composition. We say that kind is the provisional kind of 
m(vars?*") in D when an action of that kind is contributed to the composition by some component. 
Hence we define the predicate Prove” as follows: 


D-) in D may be different from the 


Dy D,Ci,7 
Prove 2= VV Poa 3 
1<i<n 


Signature predicates 


We account for subsumed inputs and hidden outputs in the signature of DExpanded by appending 
special case formulas to the predicates Prove) to form the signature predicates Pe The three 


cases we must consider are: 


e An action 7(vars?:”) is an output action of D if and only if it is an output action in some 


component C; of D and is not hidden in D. 
e An action 7(vars?") is an input action of D if and only if it is an input action in some 
component C; of D, but not an output action in any component of D. 
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a) 


e An action m(vars is an internal action of D if and only if it is an internal action, or a 


hidden output action, in some component C; of D. 


Translating these requirements into first-order logic, we derive the following definitions for the 
signature predicates of DExpanded: 


Dyn ee Dyn Dyr 
© Puy = Provoi, A 7H 

Dy .. Dir Dir 
e Pi u= Prov; A 7Prov ois 


© PP :— Proy?™ v (Prov A HPA) 


? 
ant ant out 


7.4 Semantic proof obligations, revisited 


We are now ready to formalize the following proof obligations on composite automata introduced 
in Section 


¥ Only output actions may be hidden. 
¥ The components of a composite automaton have disjoint sets of output actions. 


V The set of internal actions for any component is disjoint from the set of all actions of every 
other component. 


Below we give corresponding formulas in first-order logic that must be verified for a composite 
IOA program to represent a valid I/O automaton. In order to express the latter two of these 
obligations in first-order logic, we break each of them into two parts. First, we consider different 
components from different clauses of the components statement (i.e, Cj; # Cj). Second, we 
consider instances of the same parameterized component distinguished only by parameter values 
(ie., Ci[vars?%] # C;[vars’?“]). We use these formulas to help construct the expansion of 
transitions of composite automata in Sections [7.7}{7.9] 


Hidden actions 


The first of these obligations is just the requirement that 


V HDT > Proy?™ 


out * 


Output actions 


For output actions, we first require that different parameterized components have disjoint sets of 
output actions. Formally, we say that for all distinct components C; and C; of D, all values of the 
action parameters vars?” for 7, all values of the composite automaton parameters vars”, and all 


values of the component parameters vars?*“ and vars?’ , we require that 
D,Ci,7 D, Cj, 
v a v =F park : (7.1) 


Second, we require that different instances of the same parameterized component have disjoint 
sets of output actions. That is, for each component Ci of D, all values of the action parameters 
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vars? for 7, all values of the individual parameters vars? of the composite automaton, and all 


pairs of values of the component parameters vars?’® and vars'?:@, we require that 
Jv (eee A Plc a por A ea) => yars?% = yars'! 2% (7.2) 


where P’S" ig P&;" evaluated on vars!/?*™, 
In Example these requirements are satisfied trivially, because the output actions in the 
different components of Sys have different labels. However, the composition 
automaton BadSys1l 
components Pi[n:Int] where 0 <n An < 10; 
P2: P(5) 
would violate the first requirement, because components P1[5] and P2 share an output action, and 
the composition 
automaton BadSys2 
components W[what:Set[Int]]: Watch(Int, what) 
where what = between(1,1) V what = between(1,2) 
would violate the second requirement because components W[[1]] and W[[1,2]] both have found(1) 


as an output action. 


Internal actions 


Similarly, we break the last of these semantic proof obligations, which concerns internal actions, into 
two parts. We first require that internal actions are defined in one component only for parameter 
values where no action is defined in any other component. Formally, we say that for all distinct 
components C; and C; of D, all values of the action parameters vars?'™, and all values of the 
composite automaton non-type parameters vars? , we require that 


D,Ci,n D,Cj,0 
C PAO Sap (7.3) 


ont 


D,Cj,7 


a so 3e $ D,G, DCG, D,G, 
where P_ is the disjunction of P,’~?" oe ae 


in ’ Eon ’ and Pin 

Second, we require that internal actions of one instance of a parameterized component are 
defined only for parameter values where no action is defined in any other instance of that component. 
That is, for each component C; of D, all values of the action parameters vars”, all values of the 
composite automaton non-type parameters vars”, and all pairs of values of component non-type 
parameters vars?>% and vars'? Ci we require that 


v aes A PPG p PL® p apa = vars?:% = yars'?%, (7.4) 


out ? int 
predicate is the evaluation of the predicate on vars’ ?>@., 


Note, although allowed by obligation|7.4] the cases where pov A pe or P 
are already disallowed by semantic proof obligations and respectively. 


where peng is the disjunction of Po. PICU and P’@.™ and where the primed form of each 


ce" Poe hold 


ant out 


Claim 1 (Signature compatibility) Semantic proof obligations taken together with the 
signature where predicates Poe imply that DExpanded fulfills the semantic proof obligations for 
primitive automata 4.3 


In Sections 7.9, we argue that remaining obligations for primitive automata (4.4| and |4.5) 
are discharged by the transition where clauses of DExpanded. 
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7.5 Expanding initially predicates of composite automata 


In Section 5.2] we described the state variables of a composite automaton D. Corresponding to each 
component C; is a state variable C; with sort States| Aj, actualTypes? Ci) if C; has no parameters and 
with sort Map[types?’“, States[A;, actual Types? Ci] otherwise. Here, we describe the construction 
of an initially predicate that constrains the initial values of these state variables. This predicate is a 
conjunction of clauses, one per unparameterized component and two per parameterized component. 

If a component C; is not parameterized (i.e., the state variable C; is a tuple, not a map), then 
a single clause asserts that, for all values of the component parameters for which the component 
is defined (i.e., when P?’@ is true), each element of the tuple has an appropriate initial value. 
Furthermore, the clause asserts that, when P?:“ is true, the tuple as a whole satisfies the initially 
predicate Pe ‘, of the component. In order to account for initial values specified as nondeterministic 


int 
choices, we proceed as follows. Let 


e X; be the set of indices k of state variable declarations of the form 


F oats ‘ Ci 
tp:Ty, := choose vz:T;, where PF itk 


in the definition of the component C;, 
e cVars™ be a set of distinct fresh variables v;,:Tj,, one for each k in Xj, 


e xinitVals™ be initVals@ with each of the above choose expressions replaced by the corre- 

sponding vj,:7}, for each k in X;, and 

® +P be loan , with Uy substituted for v, when k € X; and the predicate true otherwise. 
Then we formulate the clause (shown in Figure corresponding to C; in the initially predicate 
of DExpanded by factoring out, and existentially qualifying, the variables (i.e., cVars™) used to 
choose nondeterministic values for the state variables of the component automaton Cj. 

When a component C; is parameterized (i.e., the state variable C; is a map, not a tuple), then 
there are two clauses for the component. The first is analogous to the single clause for the simple 
case in which the state variable is a tuple, but now it asserts that each element of each tuple in the 
map has an appropriate initial value and that, when P?:“ is true, the map as a whole satisfies the 
initially predicate of the component. The second clause asserts that the map is defined exactly for 
the values of the component parameters for which the component itself is defined (i.e., when P?:@ 
is true). This second clause is also asserted automatically as an invariant of the automaton. That 
is, no transition either extends or reduces the domain over which the map is defined. Figure 
summarizes these two cases and the invariant. 


7.6 Combining local variables of composite automata 


Just as it helped to collect the local variables from all transition definitions for an action 7 when 
desugaring a primitive automaton (see Section |4.3), it helps to collect the local variables from the 
transitions definitions from different components for an action 7 when expanding the definition of 
a composite automaton. Hence, we parameterize every transition definition by n per-component 
aggregate local variables that are named for the components C},..., Cp just as the n per-component 
aggregate state variables are named for those components (see Section [5.2). 
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states 


sy 


C;: States[A;, actualTypes?™), % if vars? is empty 
Say 
Cj:Map[vars?’@, States[A;, actual Types?’ ]), % if vars?*% is not empty 


initially 
iN 


P?.% = AcVars@% (Pe 


anit 


A C;j.stateVars® = xinitVals™ A Nkex; ore A 
zl 
Vuars?Ci (p24 => AcVars@ (Pi, A C;{vars?%].stateVars@ = init Vals@ 
C; 
\ Nrex, +P) \ 


Vuars?% (PPC <> defined(C;[vars?»@])) A 


invariant of DExpanded : 
sae 


Vuars?»%i (PP-Ci <> defined(C;[vars?>%])) ; 


Figure 7.2: General form of the states in the expansion of a composite automaton 
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The sort of each per-component local variable depends on the name of the action and the param- 
eterization of the component. If the component C; has no parameters, then the aggregate local vari- 
able C; has sort Locals|Aj;, actual Types? Ci ar]. On the other hand, if the component C; has param- 
eters, then the aggregate local variable C; has sort Map[types?>“, Locals[Aj, actual Types? , a's 
where types?’@ is the sequence of types of the variables in vars?:™. 

We define local Vars?™ to be the sequence of the per-component local variables C,...,Cy. If 
a transition 7 has no local variables in component C; or if 7 is not a transition in component Cj, 
we omit C; from local Vars?. We also define the sort Locals[D, types? , 7] to be a tuple sort with 
selection operators that are named, typed, and have values in accordance with the variables in 
localVars?) . 


7.7 Expanding input transitions 


Composition combines the transitions for identical input actions in different component automata 
into a single atomic transition. An input transition is defined for an action_m exactly for those 
values of vars?* that satisfy the signature where predicate Pe Figure shows the general 
form for the definition of a combined input transition based on this observation. Below, we discuss 
the definitions of the where, eff, and ensuring clauses which appear in that figure. 

Each of these clauses also appears as part of the expanded transitions for output and internal 
transitions, so we name them ae Prog?", and ensuring)”, respectively, and include them in 
the figures for the output and internal transitions only by reference. In those transitions, ia 
refers only to the predicate explicitly appearing in Figure That is, without the implicitly 
conjoined signature predicate pom 


transitions 


D,Ci,r 


input 7(vars?; local localVars?") where /\,<,<, P;, : 


eff 


% When vars?’ is empty 
: D,C; Ci, Ci, : 
in P A P.-’" then Prog,’ fi; 


% When vars?’ is not empty 


en 
for vars?>%i where P?.G% A aN, ™ do 
C;, 
Prog,, i 
od; 


: a DOG 
ensuring /\,<;<, ensuring; "" 


Figure 7.3: General form of an input transition in the expansion of a composite automaton 
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where clause 


Since there is only one input transition for the action 7 in DExpanded, the expanded transition 
where clause trivially satisfies semantic proof obligation [4.5] and its only functional role is to define 
the initial values of the local variables local Vars?’" that correspond to a given sequence of action 
parameters vars?:™. While the signature where predicate ppm need only establish that there exists 
some instance of some component that contributes an input action m(vars?”), the transition where 
predicate must define local variable initial values for each contributing instance of all contributing 
components. 

We define the input transition where clause as by constructing subformulas a »™ Each 
such subformula constrains the initial value of one local variable C; of contributing component C;. 
The where clause shown in Figure is then just the conjunction of these predicates a oO” for 
all components. 

The subformula as ©” is the implication that for each instance of the component that con- 
tributes to the transition, the local variable C; satisfies the proper initial constraints. The initial 
value of local variable C; in localVars?” is properly constrained when it satisfies the where clause 
PO for the input transition definition of 7 in component C; (for the given values of the compo- 


an,ts 
DLC: Or) 


nent parameters vars and action parameters vars . Thus, the consequent of the subformula 


implication is ae 

When the component is parameterized, the local variable C; is a map and each entry C;|vars 
in that map corresponds to the aggregate local variable for one instance of the component. In this 
case, the initial values for entries corresponding to all contributing instances must initialized. An 
instance of component C; contributes to the transition t(vars?:") when component parameters 
vars?» satisfy both the component where clause P?:“ and the signature where clause pour in 
that component (for the given values of the action parameters vars?”). Thus, the antecedent of 
the implication is the conjunction of these two predicates. To cover all instances, the implication 
is universally quantified over all values of the component parameters vars?>°:. Hence, we define 

P?PCum = Y yarsP% (Cae A Ee) => Poy) ‘ 


anti in,ty 


Gs) 


Since component C; satisfies the semantic proof obligation [4.4] there must exists a value for local 
variable C; that satisfies the above consequent whenever the antecedent holds. Thus, the implication 
is always true when read with the existential quantifier over the local variables localVars?” that 
is implicit in the transition header. Thus, DExpanded also (trivially) satisfies semantic proof 
obligation [4.4] for input transitions, since whenever the input action m(vars?”) is defined in the 
signature of DExpanded, the input transition 7(vars?") is also defined. 

Notice that for each distinct value of vars?:“ the predicate P nail 


: mentions a distinct local 
an,ts 
ics 


variable C; or C;[vars in localVars?. So, the truth values of instantiations of the the impli- 
cation are independent even though there is only one existential instantiation of the local variables 
localVars?). 

However, the fact that the implication is always true does not mean that it is equivalent to 
omit the expanded transition where clause. It is a consequence of the expanded signature where 
clause pow that some value of vars?’ satisfies the above implication antecedent. In that case the 
where clause asserts that the initial value o the relevant local variable must satisfy the contributing 
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an,ty* 
. . D,Ci, Ci, ; 
When the component is not parameterized, P;,’,"" reduces to P;,;". To see this, first, note 


that the universal quantifier simplifies away for lack of variables to quantify. Second, note that 
P?:% and pe are true whenever poe is true. So the implication reduces to just the consequent. 


component transition where predicate P. 
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Since the only functional role of the where clause is to define the initial values of the local 
variables local Vars? ‘™ when there are no local variables or when no local variable appears in any 
Par. the where clause can be omitted altogether. 


eff clause 


The eff clause performs the effects of all input transitions of each contributing instance of all 
contributing components. It contains a conditional statement for each unparameterized component 
C; of D and a loop statement for each parameterized component C; of D. 

The predicate in the conditional statement for an unparameterized component C; (when im- 
plicitly conjoined with the where clause for the entire transition and where clause for the action 
in the automaton signature) is true if C; contributes an input transition for 7 to the composite 
automaton D. In that case, the body of the conditional statement executes the program in the eff 
clause in the transition definition for 7 in Cj. 

The situation is slightly more complicated when the component C; is parameterized, because the 
transition must execute the effects of all instances of the component that contribute to the action. 
Thus, the eff clause loops over all the different values of the component parameters vars?’@ that 
satisfy the component where clause P?:“i and the signature where clause pe in that component 
to execute the program in the eff clause in the transition for 7 in that instance of component Cj. 
Notice that each instance of a contributing component C; (corresponding to one iteration of the 
loop for C;) manipulates a distinct tuple of local variables C;[vars? Ci) P2) 

If only one unparameterized component C; contributes to the input transition definition, the 
conditional statement for that component may be replaced by the eff clause in the transition 
definition for 7 in C; itself because the guard is implied by poe. 


ensuring clause 


The ensuring predicate must be true if and only if the ensuring predicate from each contributing 
instance of all contributing components is true. That is, given the parameters vars?”, for each 
D.C of each component C; that satisfies both the 


con in that component, the value 


sequence of values of component parameters vars 


component where clause P?:“ and the signature where clause P 


D- must also satisfy the ensuring clause ensuring ’™ for the 
input transition definition of 7 in C;. Thus, we define the predicate ensuring? Co" 


um 
the the predicate P?:@": 


an,t1 


of the local variable C; in local Vars 
analogously to 


; D ty 4 4 ay 4 4) 
ensuring,’ © ™ = V vars?© (Cae A Pe E) => ensuring @ a 


in,ty 


Currently, IOA syntax permits only a single single loop variable in for statements. However, if V is a sequence 
of variables v1, v2,v3,..., then it is simple to rewrite multi-variable loops such as the ones used in Figure [7.3] 


for V where p do g od 


as nested single-variable loops using the inductive step 


for v; where 4V'p do 
for V’ where p do g od 
od 


where is the variable sequence V’ = v2,v3..., p is a predicate and g is a program. 
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7.8 Expanding output transitions 


We build up to the general form of expanded output transitions by first considering three spe- 
cialized cases. The simplest case we consider is an output transition that appears in exactly one 
unparameterized component and in no component as an input transition. Second, we consider the 
expansion of an output transition when that sole contributing component is parameterized. Third, 
we extend our definitions to apply output transitions contributed by multiple components. Finally, 
the fully general expansion of output transitions covers the case where output actions and input 
actions share a name. 


Output-only transition contributed by a single unparameterized component 


We begin by considering the simplest case of an output transition m(vars?) that appears in exactly 


one unparameterized component C; and in no component as an input transition. That is, there is 
no component C, whose signature contains an input action m(vars?""), In this case, the expanded 
output transition does not need to be performed atomically with any input transition. 

As there is only one transition contributing to the expansion, there is only one transition for the 
action 1(vars?*) in DExpanded. Thus, the expanded transition where clause trivially satisfies 
semantic proof obligation and its only functional role is to define the initial values of the local 
variable C; that corresponds to a given sequence of parameters vars?:. In this case, simply reusing 
the component transition where clause aperey as the expanded transition where clause gives the 
correct definition. In fact, the only difference between the expanded transition and the component 
transition in this simplest case is the way locals variables are declared in transition header. The 
aggregate local variable of the component transition becomes the sole local variable of the expanded 
transition. The resulting form is show in Figure 


transitions 


output m(local vars?:“, Cj:Locals[C;, actual Types?’ , 7) 
Ci, 

Pine 

Cyr 

out 


eff Prog i 


where 


pre Pre 


° . Cyr 
ensuring ensuring 51} 


Figure 7.4: Expanded transition for an output action with no matching input actions, derived 
uniquely from a component C; with no parameters. 


Output-only transition contributed by a single parameterized component 


When the component C; has parameters the expansion is slightly more complicated. As in the 
previous case, no like-named input transitions exist in any component and, therefore, the expanded 
output transition does not need to be performed atomically with any input transition. Also like the 
previous case, there is only one transition definition for t(vars?) in the expanded automaton, so 
the transition where clause trivially satisfies semantic proof obligation and its only functional 
role is to define the initial values of the local variables. Unlike the previous case, the state and 
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transitions 


output 2(vars?; local vars)», Cj:Map[types?©, Locals[C;, actual Types?’ ©, r]]) 


where P?:C a P&T Poe 
Cyr 


out 


eff Prog i 


pre Pre 


Cia 


ensuring ensuring 51} 


Figure 7.5: Expanded transition for an output action with no matching input actions, derived 
uniquely from a parameterized component C;. 


local variables C; are maps rather than simple tuples and the contributing component parameters 
vars? are introduced as local variables. 

The initial values of vars?“ need to be the correct indices for the relevant entry in the state and 
local variable maps. That is, C;[vars?:“] should evaluate to the tuple derived from the aggregate 
variable of the contributing instance of the component. Note, the semantic proof obligation 
requires that at most one instance of a component may contribute an output action n(vars? we 
In fact, proof obligation [7.2| provides the formula for selecting the correct indices. The component 
parameters of the sole contributing instance uniquely satisfy both the component where clause 
P”:% and the signature where clause Pout Thus, these two predicates appear as conjuncts in 
the where clause. 

Since at most one instance of component C; contributes to the expanded transition, at most 
one entry in each of state and local variable maps C;, corresponding to the aggregate variable of 
the contributing instance of the component, has any relevance to the transition. The other entries 
are completely ignored P| The initial values for that entry C;[vars?’©'] are those that satisfy the 
component transition where clause P , Thus, this predicate forms the last conjunct in the 
expanded where clause. 

The fact that at most one instance of component C; contributes to the expanded transition 
also means the expanded definition for the transition of an output action 7 need not use a for 
statement, as does the expanded definition for the transition of an input action. Instead, the 
expanded definition simply reuses the eff clause of the sole contributing component transition. 
Similarly, the pre and ensuring clauses of the expanded transition are the same as those of the sole 
contributing component transition, as shown in Figure [7.5] 


Output-only transitions contributed by multiple components 


When an output action name appears in several components, it would be valid for the expanded 
composite automaton to include a separate output transition derived from each contributing com- 
ponent transition using the above definitions. Unfortunately, as we see below, this approach yields 
a code-size explosion multiplicative in the number of like-named input and output transitions. To 
avoid this code explosion, we define the expanded composite automaton to combine all like-named 


?3Tn this special case, the references to local variable maps (rather than simple tuples) introduced by substitution 
Ji,x rule [9]in Section [6.3] are actually an unnecessary complication. However, they are required in the more general 
cases discussed below. 
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transitions 


output m(vars?™; local vars?’™,..., vars?>%, local Vars?”) 
D,C; Cin Cin 
where Vi<i<n (P \ ee A Pd 
DC; Ci,7 Ci,7 
pre Vicien (P N Pak hE ea ) 
eff 
if... 

. DC; Cir Ci,7 
elseif P A Poi then Prog oi} 
elseif ... 
fi 


Cyr 
out, ty 


ensuring /\\<;<y Cae A P = ensuringt ) 


Figure 7.6: Expanded transition for an output action with no matching input actions, contributed 
by several components 


output transitions into a single output transition, as shown in Figure [7.6] An additional advantage 
of combining all like-named output transitions is that, once again, the expanded transition where 
clause trivially satisfies semantic proof obligation and its only functional role is to define the 
initial values of the local variables. 

In the expansion, we declare as local variables the parameters of each (contributing) component 
and the local variable C; from each (contributing) component. As in the previous case, the semantic 
proof obligations for output actions given in Section[7.4|provide the key to defining the where clause. 
Obligation [7.1] requires that for any value of parameters vars?:7, at most one disjunct of 

VV PP»Cum — VV AvarsP?C% (PPC Pi) 


out out 
1l<i<n 1l<i<n 


can be true. That is, at most one component may contribute an output transition n(vars? my 


Since, all the component parameters vars?:© appear as local variables in the expanded transition 
header, these variables are implicitly existentially quantified in the where clause. Therefore, in the 
expanded transition, the above obligation can be expressed simply as 


Vie AP) 


out 
1l<i<n 


Similarly, obligation requires that at most one set of values for the component parameters 
vars?» of that contributing component C; satisfies the conjunction 


DLC; Cit 
PPG p pOur 


That is, at most one instance of that component may contribute an output transition m(vars? m 
Notice that this conjunction appears exactly in the previous obligation. In fact, we use the conjunc- 


tion of the component where clause P?’“ of the contributing component and the signature where 
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clause par as a “guarding conjunction” for selecting the contributing instance of the contributing 
component throughout the expanded output transition. 

In the where clause the guarding conjunction is paired with the corresponding component tran- 
sition where clause and that triple conjunct is disjoined over all the components. Doing so has the 
effect that the initial values of the relevant local variable C; (or its relevant map entry C;[vars?’“]) 
satisfies the component transition where clause whenever C; is the contributing component. 

Notice, it is a consequence of the expanded signature where clause ppm that some value of 
vars?“ satisfies the guarding conjunction. Furthermore, since component C; satisfies the semantic 
proof obligation there must exists a value for local variable C; that satisfies the consequent 
whenever the guarding conjunction is true. Therefore, whenever the output action 1(vars?%") is 
defined in the signature of DExpanded, the output transition m(vars?7) is also defined. Thus, 
DExpanded also satisfies semantic proof obligation [4.4] for output transitions. 

In the precondition, the guarding conjunction is paired with the corresponding component 
precondition and that triple conjunct is disjoined over all the components. Thus, the expanded 
transition is enabled when there is a component for which all three of the transition precondition, 
the transition where clause, and the component where clause are true for the given parameters 
and initial local variable values. Checking the conjunction of all three predicates avoids enabling 
the transition when the where clause is satisfied by the transition from one component while the 
pre clause is satisfied by the transition of another component. 

In the eff clause, the guarding conjunction selects the conditional branch containing the effects 
of the single contributing output transition that is defined for the given parameters. Similarly, the 
ensuring clause of the contributing output transition must be satisfied. 


Output transitions subsuming input transitions (general case) 


When both input and output transitions are defined and (the output transition is) enabled, the 
output transition subsumes the input transitions. That is, the input actions execute atomically 
with the output action. Just as we cannot statically decide that two input actions will never 
be simultaneously executed, we cannot, in general, statically decide that an input transition can 
never be subsumed by a like-named output transition. Therefore, each expanded output transition 
must include the effects of all like-named input transitions (appropriately guarded). (It is this fact 
that would cause the code-size explosion mentioned in the previous section were we to include a 
separate output transition derived from each contributing component transition.) Figure|7.7|shows 
the general form for expanding output transitions of composite automata. 

In the cases where the output transition subsumes one or more input transition, the local 
variables from the instance(s) of the component(s) contributing the input transition(s) must be 
initialized by the expanded transition where clause. On the other hand, the where clause must 
still always be satisfiable when an output action is defined. As we argue in Section the 
expanded input transition where predicate ras does exactly these two things. First, it requires 
the local variables derived from contributing input transitions to satisfy the where clauses of those 


transitions. Second, 2 is satisfiable by some choice of values for localVars?™. Thus, we simply 
Bae to the where clause developed in the previous case. 

The eff clause selects the effects of the single contributing output transition that is defined 
for the given parameters and then performs all the effects of the subsumed input transitions by 


executing Prog?™. Each effect in Prog?* is already guarded so as to occur only when the source 


conjoin P. 


transition contributes. Therefore, we simply append Prog?™ to the eff clause from the previous 
case. Similarly, the ensuring clause ensuring?” can also be simply conjoined with the the ensuring 


62 


transitions 


output 7(vars?7; local vars?“ ,..., vars? local Vars?™) 
where V/j<i<n (pee KPa K Et) ae an 
pre Vi<icn (Pee \ Pos A Presi) 
eff 
If 34%: 
elseif P2% A PO" then Prog@;” 
elseif ... 
fi; 
Prog?™ 


Cyr 
out 


: ; A sD 
ensuring Ni<i<n (p> A P => ensuring: ) A ensuring ;,"" 


Figure 7.7: General form of an output transition in the expansion of a composite automaton 


clause from the previous case. 

Note that, Prog?™ may, in fact, amount to a no-op in all executions. However, in general, 
this cannot be statically decided. Also note that the order of execution of the subsumed input 
transitions with respect to each other or to the enabled output transition does not matter. The 
semantic checks require that each conditional branch or for body executed in either the subsumed 
input transition or the remainder of the clause must be derived from distinct automata. These 
effects can alter only the value of state, local, or choose variables derived from the automaton 
contributing that effect. Furthermore, the effects can depend only on those same set of state, local, 
and choose variables or on the parameters of the transition. No effect can change a parameter 
value. 

We define Prog? to be the program in the eff clause that combines the effects of output 
transitions and subsumed input transitions. Similarly, we define ensuring? to be the predicate 
that appears in the ensuring clause. 


7.9 Expanding internal transitions 


The basic form of expanded internal transitions is analogous to that of output actions. The most 
significant difference is that the internal transition expansion must account for output actions that 
are (potentially) hidden. So before we consider the general expansion for internal transitions, we 
build on the discussion of the expansion of output transitions above to consider the the simpler case 
of expanding transitions for internal actions when there are no hidden clauses for those actions. 
We then discuss how to generalize this construction to account for hidden output transitions. 


Internal-only transitions 


The expanded form of the transition for an internal action when there is no hidden clause for that 
action follows a pattern similar to that of output transitions when there are no like-named input 
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transitions 


internal r(vars?; local vars?:“,..., vars?°, local Vars?”) 


D,C; Cin Cin 
where Vj<j<n (P AE IOP, ) 


ant,ty 
pre 
D,C; Ci, Ci, 
Vi<i<n (P \ or A Pe”) 
eff 
if... 

° ; Ci, Ci, 
elseif P?-% A Pov" A then Prog;';" 
elseif ... 
fi 


ensuring /\,<;<, (Ppa A Par 


Ayr 
int ty ensuring’ ) 


Figure 7.8: Expanded transition for an internal action with no matching hidden clause 


transitions. In that expansion, shown in Figure[7.8} we introduce local variables for the parameters 
of each contributing automaton as well as all the local variables from all the contributing transitions. 
Following reasoning analogous to the output case, we use the conjunction of the component where 
clause P?:% of the contributing component and the signature where clause ei as the guarding 
conjunction for selecting the contributing instance of the contributing component throughout the 
expanded internal transition. 

In the where clause, the guarding conjunction is paired with the component where clause 
for the contributing transition one to initialize the local variable values. In the precondition, 
the guarding conjunction is paired with the pre predicate of the contributing transition. In the 
eff clause, the guarding conjunction selects the conditional branch containing the effects of the 
single contributing transition that is defined for the given parameters. In, the ensuring clause, the 


contributing transition ensuring clause must be satisfied when the guarding conjunction holds. 


Internal transitions with hiding (general case) 


The most important difference between the expansion for internal transitions and that for output 
transitions is that the internal transition expansions must account for output actions that are 
(potentially) hidden. We cannot, in general, statically decide whether the hidden predicate H?* 


covers the output signature predicate P,,7"._ Nor can we, in general, statically decide whether 
Cyr 
out,ty° 


action 1(vars mentioned by a hidden clause must be incorporated into the expanded composite 
automaton twice, once in an output transition and once in an internal transition. 

One way to do this, would be to include two internal transitions for each transition 7(vars 
The first transition would be derived as in the previous section, ignoring any hidden output actions. 
The second transition would be a second copy of the expanded output transition m(vars?"). This 
transition would be identical to the general case output transition expansion except it would be 
labeled internal. 


H?:" covers the where clause for any contributing transition P Thus, each transition for each 


ae 


EY, 
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An alternative expansion is shown in Figure[7.9] This expansion follows the pattern of including 
just one transition of each kind. An advantage of having just one transition is that the expanded 
transition where clause trivially satisfies semantic proof obligation and its only functional role 
is to define the initial values of the local variables. 

Proof obligations and [7.4] imply that, over all components, at most one of the conjunctions 
Beef Fake and P?:% A par can be true. So these conjunctions are used as the guard- 
ing conjunctions for the expanded transition. The former guards elements derived from internal 
component transitions. The latter guards elements derived from output component transitions. 

In the where clause, each guarding conjunction is paired with the component where clause for 
the contributing transition raed tt of matching kind to initialize the local variable values. Since a 
hidden output transition might also subsume a like-named input action, the where predicate also 
asserts Poe In the precondition, the guarding conjunction selects the appropriate component 


Cyr 
int 
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or Pre ju} 


to satisfy. These latter disjuncts are abbreviated by 
referencing the expanded output pre predicate Pre? The eff clause selects the effects of the 
single contributing internal or output transition that is defined for the given parameters and then 
performs all the effects of the subsumed input transitions. The conditional selecting the effects of 
an internal action is shown in the figure. Effects derived from hidden output and hidden subsumed 


inputs are executed in the appended program Prog?" Similarly, the ensuring clause from the 


transition precondition Pre 


previous case can be simply conjoined with expanded output transition ensuring clause ensuring? 

Notice, it is a consequence of the expanded signature where clause ae that some value of 
vars? satisfies one of the guarding conjunctions. Furthermore, since component C; satisfies 
the semantic proof obligation there must exists a value for local variable C; that satisfies 
the consequent whenever a guarding conjunction is true. Therefore, whenever the internal action 
m(vars?") is defined in the signature of DExpanded, the internal transition (vars?) is also 


defined. Thus, DExpanded also satisfies semantic proof obligation [4.4] for internal transitions. 


?4We cannot simply conjoin Poe to the transition where clause because pb would not distribute correctly. 
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transitions 


D,Cy 


internal 7(vars?™; local vars yee, varsPrOn, localVars?™) 


where Wied, (2? A pot A Poe) V Cae A pot A Pout )) A por 


ant ant,ty out out,ty an,ty 
pre 


DC; Ci, Ci,0 Dir 
Vi<i<n (P Ae age ia ee ) V Pre out 
eff 


if... 
elseif P?>% , P&™ \ then Prog" 


ant ant 


elseif ... 


fi; 


Dir 
Prog oj: 
Cyr 
ant,ty 


: . SA ain 
ensuring Aj <;<y (BB A P = ensuring’ ) A ensuring): 


Figure 7.9: General form of an internal transition in the expansion of a composite automaton 
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8 Expansion of an example composite automaton 


In this section, we detail the expansion the composite automaton introduced in Example[2.4] In this 
expansion, we apply the techniques described in Section [7] to the composite automaton Sys shown 
in Figure and to the canonical versions of its component automata shown in Figures |6.3 
In Section [8.2] we derive the signature of SysExpanded in three stages. In Section [8.3] we describe 
the state of the expanded automaton, including its initial values, and an invariant about the scope 
of definition for its state variables. 

Where convenient, we recapitulate definitions developed in previous sections in summary tables 
to save the reader (and the authors!) from having to flip back to look up definitions. 


8.1 Desugared hidden statement of Sys 


Following the procedure described in Section [7.2] we eliminate terms other than variable references 
from the parameters of the hidden statement of automaton Sys by replacing params, ysons = 


Sys,send _ ( hide 


(nProcesses, nProcesses+1, x:Int) with vars ni:Int,n2:Int,m:Int), defining 0° to 
map m:Int to a fresh variable i: Int, and rewriting the where clause in the hidden statement to 


produce 
hidden send(ni, n2, m) 
where Jj i:Int (i =m A nit = nProcesses A n2 = nProcessest1i) 
which simplifies to 
hidden send(ni, n2, m) where ni = nProcesses A n2 = nProcesses+1l 


Thus, we define H®YS:Se24 to be ni = nProcesses A n2 = nProcessestt. 


8.2 Signature of SysExpanded 


To expand the signature of composite automaton Sys as described in Section [7.3] we first calculate 


,Ci,7 


the per-kind, per-action, per-component predicates peys . Then we combine these by compo- 


nent to form the provisional kind predicates Proves. Finally, we combine these predicates with 
the hidden statement predicate to derive the signature predicates pe psysin and pee, 

In computing these predicates it is helpful to remember the component predicates and canonical 
variables of the sample composite automaton Sys. Table [8.1] collects the former from Example [2.4] 
Table recalls the latter as they were defined in Example The local variables shown are 


derived from Example [6.2|as described in Section [7.6] 


PREDICATE | VALUE 

pSys.C j = itt A 1 <i Ai < nProcesses 
psys.P 1 <nAn < nProcesses 

poem true 


Table 8.1: Component predicates of the sample composite automaton Sys 


Actions per component 


First, we define predicates for each kind of each action for each component. Sys has three compo- 
nents and four action names, each of up to three kinds. Thus, there are thirty-six possible per-kind, 
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CANONICAL SEQUENCE | VARIABLES 


vars®¥s nProcesses: Int 

vars© n:Int 

vars? n:Int 

vars°¥8,send ni:Int, n2:Int, m:Int 
vars©ys.receive ni:Int, n2:Int, m:Int 
vars®¥8,overflow i1:Int, s:Set[Int] 
vars°ys,found i1:Int 


P:Map[Int, Locals[P, overflow]], 
local Vars®¥8:0vVert low 


W:Locals[Watch, Int, overflow] 


Table 8.2: Canonical variables used to expand the sample composite automaton Sys 


per-action, per-component predicates pr. Table|8.3|shows the seven of these predicates that 


are not trivially false. All the existential quantifiers have been eliminated from the predicates shown 
in the table. 

We can simplify such a predicate by dropping existential quantifiers and conjuncts that are 
superfluous. A quantifier is superfluous if the predicate equates the quantified variable directly 
with a term not involving a quantified variable. The conjunct that equates the quantified variable 
to a defining term is also superfluous. The simplification proceeds in four steps: 


1. Define a substitution that maps any superfluous existential variables to the corresponding 
term. 


2. Apply the substitution to the predicate. 
3. Delete identity conjuncts from the where clause. 


4. Delete the existential quantifiers for variables that no longer appear in the predicate. 


For example, by the definition given in Section 


poysC,send 


un 


AvarsSV=:C (peyaiG A p een) 


= dn:Int (1 < nA n < nProcesses A nit =n A n2 = nti) 


We simplify this predicate by defining and applying a substitution that maps n:Int to ni:Int, 
delete the resulting identity conjunct, the quantified variable, and the quantifier, resulting in the 
predicate shown in Table 


Provisional action kinds 


Since no two components of Sys share the same kind of any action, it is simple to define the 


? 


provisional kind predicates Proves. Seven of the twelve possible predicates are not trivially 


false. Each of these has exactly one nontrivial disjunct—the corresponding predicate pe. as 


shown in Table 
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PREDICATE VALUE 
psy® ,»C,send 


Pe (14 < nt A ni < nProcesses) A (n2 = ni1+1) 
pees send (1 < ni A ni < nProcesses) A (n2 = nit+i1) 
pov MRESSENS (1 < ni A ni < nProcesses) A (n2 = nit+1) 
pryes receive (1 < n2 A n2 < nProcesses) A (ni = n2-1) 


im 
Sys,P,overflow 
Fa 
peys , W,overf low 
prs ,W,found 


out 


1 < it A il < nProcesses 


ii € between(1, nProcesses) 


il € between(1, nProcesses) 


Table 8.3: Simplified predicates defining contributions to the signature of Sys 


PREDICATE VALUE 
Sys,send Sys,C,send 
Prov, Pe 
Sys,send Sys,P,send 
Prov out aut 
Sys,receive Sys,C,receive 
Prov out Fc 
Provsverecetve Pres 
Sys,overflow Sys,P,overflow 
Prov out ee 
Proved sovert iow Pare Diets ron 
Sys,found Sys,W,found 
Pr out eee 


Table 8.4: Provisional where predicates for the signature of Sys 
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Signature predicates 


eons 2 2 S iS) Sys, ‘ 
We now compute the nontrivial signature predicates | ase poe. and po for the four action 


labels send, receive, overflow, and found of automaton SysExpanded. 


Output actions We compute the signature predicate for output action send, by applying the 
formula 


poys.send =p Sys,P,send A — ff Sys.send_ 


out out 


Using the desugared form of the hidden predicate shown in Example|7.2| we find that pore 


- 1 < ni A ni < nProcesses A n2 = nit+l 
A a(ni = nProcesses A n2 = nProcessest1) 
Computing the predicates for output actions receive, found, and overflow is simple because 
there is no hidden clause applying to them (i.e., H®Y®:7 is false) and the action predicate is, in 
fact, just the provisional kind predicate, as shown in Figure 


Input actions We compute the signature predicate for input action send by applying the formula 


Sys,send _ Sys,send Sys,send 
oa = Prov,,” A aAProv jin : 
iS) d 
Thus, P?**°"° evaluates to 


in 
1 < ni A ni < nProcesses A n2 = nit+l A 
a((1 < ni A ni < nProcesses) A (n2 = ni+1)) 


The signature predicates for input actions receive, and overflow are computed similarly and 
appear in Figure 


Internal actions In Example [2.4] the component automata have no internal actions. Therefore, 


Sys,send . 


the only internal action in Sys is the hidden action send. Thus, the predicate P is equivalent 


to 


ant 


s d 
Reg re A Sys, send 


out 


which evaluates to 
1 < nit A ni < nProcesses A n2 = niti A ni=nProcesses / n2=nProcessest1 


The complete expanded signature of automaton Sys is given in Figure [8.1] 


8.3 States and initially predicates of SysExpanded 


The complete expanded state of automaton Sys is given in Figure [8.1] Since each component of the 
desugared composite automaton has non-type parameters, all three state variables are maps. Three 
of the initially subclauses (and the subsequent invariant) assert the well-formedness requirement 
that each map is defined only for values of the component parameters on which the component itself 
is defined. The other three initially subclauses assert that the contents of each channel is initially 
empty, the watch process is looking for values between 1 and nProcesses and that each process P 
initially has value 0 and nothing to send. The type declaration appearing at the beginning of the 
figure is the automatically generated sort for the state of the composite automaton. 
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type States[Sys] = tuple of C:Map[Int, States[Channel,Int,Int]], 


P:Map[Int, States[P]], 
W: States [Watch, Int] 


automaton SysExpanded(nProcesses: Int) 


signature 
output send(ni, n2, m:Int) 
where 1 < ni A ni < nProcesses A n2 = niti 
A (ni = nProcesses A n2 = nProcessestl), 


receive(ni, n2, m:Int) 
where 1 < ni A ni < nProcesses A n2 = niti, 


overflow(i1t:Int, s:Set[Int]) where 1 < il A il < nProcesses, 


found(it:Int) where ii € between(1, nProcesses) 


input send(n1, n2, m:Int) 
where 1 < ni A ni < nProcesses A n2 = niti 


A 7(1 < ni A ni < nProcesses A n2 = 


receive(ni, n2, m:Int) 

where 1 < n2 A n2 < nProcesses A ni = n2-1 

A nC1 < ni A ni < nProcesses A n2 = 

overflow(il:Int, s:Set[Int]) 

where il € between(1, nProcesses) 

A aCi < it A ii < nProcesses) 
internal send(ni, n2, m:Int) 
where 1 < ni A ni < nProcesses A n2 = niti 


A ni = nProcesses A n2 = nProcessesttl 


states C:Map[Int, States[Channel, Int, Int]], 
P:Map[Int, States[P]], 
W:States[Watch, Int] 
initially 
Von:Int ((1 
Von:Int ((1 
Von:Int ((1 
Von:Int ((1 
W.seen = con 


nProcesses) = defined(C, 


nProcesses) <= defined(P, 
se) 


DINIAIAIA 


n /A 
n /A 
n /A 
n /A 
ant 


FIAIA A A 


n 
n 
n 
n 

t (fa 


invariant of SysExpanded: 
Von:Int (1 <n An < nProcesses & defined(C[n])); 
Von:Int (1 <n An < nProcesses & defined(P[n])) 


Figure 8.1: Expanded signature and states of the sample composite automaton Sys 
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nit+i), 


nProcesses) > C[n].contents = {}) 


n)) 


nProcesses) => P[n].val = 0 A P[n].toSend 


n)) 


nit+i), 


{}) 


8.4 Input Transition Definitions of SysExpanded 


We compute the input transitions of SysExpanded by following the pattern of Figure [7.3] for each of 
the input actions in its signature (receive, send, and overflow) and simplifying. Figure [8.2] shows 
the three resulting forms. 

In that figure, each input transition is formed from only a single contributing component. 
Thus, the conjunctions in the where over the contributing components in Figure [7.3] each resolves 
to a single term. Furthermore, we omit the where clauses for the receive and send transitions 
because the transition definitions have no local variables. In each of the three transitions, we 
omit the ensuring predicate altogether because the sole contributing predicate for each transition 
(ensuring® Toe? ensuring? s°n4 and ensuring°Vert low) is trivially true. The eff clause of each 
transition resolves to a single for loop or conditional. In the overflow transition, the conditional is 
replaced by its body because there is only a single contributing transition. 

Figure shows the final text of the expanded input transitions. In that figure, we omit 


the local variable P:Map[Int, Locals[P, overflow]] from the overflow transition because it does 
Sys,W,overflow 
an,ty 


reduces to the implication shown in Table [8.5] because vars©¥8" is empty and P®Y8" is trivially 
true. 

The for loops in the receive and send transitions have been eliminated by the following simpli- 
fication. Filling in the specified variables from Tables predicates from Tables and and 
statements from Example [6.2] in the receive transition for loop yields the loop 


not appear in the transition precondition or effects. The where clause predicate P 


for n:Int where (1 <n An < nProcesses A ni = n-1i A n2 =n) do 
if P[n].val = 0 then P[n].val :=m 
elseif m < P[n2].val then 
P[n].toSend := insert(P[n].val, P[n].toSend); 
P[n].val :=m 
elseif P[n].val < m then 
P[n].toSend := insert(m, P[n].toSend) 
fi 
od. 


Since the last conjunct of the loop where clause limits the loop variable to a single value, the 
transition parameter n2, we can eliminate the loop altogether. Thus, in Figure [8.3] we replace the 
loop with its body after applying to the body a substitution that maps the loop variable n to its 
value n2. Similarly, the for loop in the send transition is eliminated using a substitution that maps 
its loop variable n to the transition parameter nt. 


8.5 Output Transition Definitions of SysExpanded 


We compute the output transitions of SysExpanded by following the pattern of F igure[7.7|for each of 
the output actions in its signature (receive, send, overflow, and found) and simplifying. Figure[8.4] 
shows the four resulting forms. 

Notice that only one component contributes an output transition to each expanded output tran- 
sition. Therefore, only syntactic elements from the sole contributing component and the correspond- 
ing expanded input action appear in each transition. Each local variable list contains of the compo- 
nent variables for that contributing component. Since, local Vars®¥®:Te°*tVe , Jocal Vars8V*: 8°24, and 
localVars®Y:fOUnd are empty, they are omitted from their respective transitions. Since component 
W is unparameterized, the found transition has no local variables at all. 

The where clause of each transition resolves to a single term rather than being a disjunction 
over the contributing components. Furthermore, we omit the where clauses for the receive, send, 
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PREDICATE VALUE 
P,receive 
Fig 


C,send 
Pan 


ni=n-iAn2=n 


ni=n/A n2 = ntl 


pW.overt low 


in ii € between(1, nProcesses) 


W,overflow 
an,ty 
Sys,W,overflow 


an,ty 


s = W.s2 U {ii} V A(il € s) 


i1 © between(1, nProcesses) > (s = W.s2 U {il} V n(il € s)) 


Table 8.5: Nontrivial predicates used in expanding input transition definitions of the sample com- 
posite automaton Sys derived from Figures and [6.5] 


input receive(varsSVS-Tece1ve ) 


Sys,P 


where 


eff for vars pSysP , pF.receive P.receive) 4 


do Prog; 


um 
input send(vars°¥S:Sen4) 


eff for vars®V8:° where P®Y8:© A pe eene do Prog?:8en4 od 


: Sys,W fl 
input overflow(vars®¥8:°verflow. Jocal local Vars®¥8:0VeFF10¥) where Pye movers tow 


an,ty 
or Prag ry 


Figure 8.2: Form of input transitions of SysExpanded 


input receive(ni, n2, m) 


eff if P[n2].val = 0 then P[n2].val :=m 
elseif m < P[n2].val then 
P{n2].toSend := insert(P[n2].val, P[n2].toSend); 
P[n2].val :=m 
elseif P[n2].val < m then 
P[{n2].toSend := insert(m, P[n2].toSend) 
fi 


input send(n1, n2, m) 
eff C[ni].contents := insert(m, C[n1].contents) 


input overflow(i,s; locals W:Locals[W,int, overflow] ) 
where i1 € between(1, nProcesses) > (s = W.s2 U {il} V 7(Cil € s)) 


eff if s = W.s2 U {iit} then W.seen[ii] := true 
elseif =(i1 € s) then W.seen[ii] := false 
fi 


Figure 8.3: Input transition definitions of SysExpanded 
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PREDICATE VALUE 


poreceive 
out 


ni=n/A n2 = ntl 


poreceive 


out,ty ni=n/A n2= ntl 


Pre ete m € C[n].contents 
poe ni =n A n2 = nti 
oeioms ni =n A n2 = ntl 
Be ees m € P[n].toSend 

P,overflow : 
Pout il=n 

P,overflow . 
eee il=n 

P,overflow ; 

Pre out s = P[n].toSend A n < size(s) A P[n].t C s 
preowned it € between(1, nProcesses) 
re ae W.seen[i1] 


Table 8.6: Nontrivial predicates used in expanding output transition definitions of the sample 
composite automaton Sys derived from Figures and [6.5] 


and found transitions because the transition definitions have no local variables. Similarly, the en- 
suring clause is only a single conjunction. In each of the four transitions, we omit the ensuring 


predicate altogether because the consequent for each transition (ensuring ete°et Ve ensuring? ;Sen4 


out ut ’ 
ensuring) overt low and ensuring {0Un4) is trivially true. Furthermore, the conditional and guard- 


ing conjunction can be omitted from the eff clause because only one output contributes. So each 
effect is just the effect of the contributing output transition followed by the effect of the corre- 
sponding expanded input transition. Since the output transition definition for the found action in 
component W has no effect and there is no found input action, the expanded found transition has 
no effect either. 


Filling in the specified variables from Tables predicates from Tables [8.1] and [8.6] and state- 
ments from Example and Figure yields the complete the complete text of the expanded 
output transitions shown in Figure[8.5] We simplify the transition definitions using two techniques. 


First, we eliminating unneeded local variables. Second, we use the fact that the signature where 
Sys,receive 


pa ) is implicitly conjoined to the corresponding transition 


where predicate (e.g., hcp acai) and precondition (Pre®¥sreceive) to eliminate redundant 
assertions in the transition where predicate and precondition. The resulting final form of output 


transitions is shown in F igure [8.6] 


To eliminate unneeded local variables, we follow the four step process to eliminate unneeded 
local variables described in Section [4.2] For example, we note that the where clause of the receive 
transiting equates n with parameter ni. Furthermore, there is no assignment to n in the effects of 
that transition. Thus, the local variable n is extraneous. So, we define a substitution that maps 
the local variable n to the parameter ni and apply it to the where, pre, and eff clauses. We then 
delete the resulting identity conjunct from the where clause and the declaration of the local variable 
n. Similarly simplifications eliminate the local variable n from the send and overflow transition 


predicate for an action (e.g., P 
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output receive(vars'J*:Teceive. local vars®Y8C) 


where psys.c A poreceive A poreceive A poyereceive 


out out, ty in,ty 


pre PSys.c a poreceive A Pre&teceive 


out out 


C,receive 
eff Prog >}. : 


Sys,receive 


Prog; 


in 


output send(vars®¥8:send. local vars®J8P) 


where Poyar A pP.send A pPsend A poys.send 


out out, ty in,ty 


pre P®YSP , po A Ppeeee 


ut out 
eff Prog’ 82"4. 


out 
Sys,send 
in 


Prog; 


Sys,C eye Oy ere tow) 


output overflow(vars®¥*:0verflow. Jocal vars ,vars°¥8P local Vars 


where P®ysP A pPoverflow A pPoverflow A poys.overtlow 


out out, ty inyts 


pre PSysP a pPoverflow A Preb:overflow 


out out 


eff Prog®:0Vett low, 


out 
Prog 


Sys,overflow 
in 


output found(varsSV8-found) 


pre Psys.W a pW.found A PreW found 


out out 


Figure 8.4: Form of output transitions of SysExpanded 


definitions. Since the resulting receive and send transitions no longer have any local variables, we 
omit their where clauses altogether. 
After this simplification, the precondition for the receive transition is 
pre 1 < ni A ni < nProcesses A n2 = ni+i Am € C[ni].contents 
However, the first three conjuncts are also asserted by the the signature where clause for the receive 
output action fe eae and, therefore, are redundant. Similarly simplifications to the where 
and pre clauses of the other transitions result in the final text of the expanded output transitions 


shown in Figure 


8.6 Internal Transition Definitions of SysExpanded 


Since no component has any internal transitions, the only internal transitions in SysExpanded is the 
hidden output send transitions. In the case where no component contributes an internal transition, 
the form in Figure reduces exactly that in Figure That is, the internal send transition 
definition is identical to the output transition definition except for its label. The two actions are 
distinguished exactly by the assertion or negation of H®Y*:8°24 in the signature of SysExpanded. 
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output receive(ni, n2, m; local n:Int) 


where 1 < ni A ni < nProcesses A ni =n A n2 = nitil 
pre 1 <n A ni < nProcesses A ni =n A n2 = nti 
Am € C[n].contents 
eff 
C[n].contents := delete(m, C[n].contents) 
if P[n2].val = 0 then P[n2].val :=m 
elseif m < P[n2].val then 
P[n2].toSend := insert(P[n2].val, P[n2].toSend); 
P[n2].val :=m 
elseif P[n2].val < m then 
P[n2].toSend := insert(m, P[n2].toSend) 
fi 


output send(ni, n2, m; local n:Int) 
where 1 <n An < nProcesses A nt =n A n2 = nt1 
A ni =n A n2 = nttl 
pre 1<nA n < nProcesses A nt =n A n2 = nti A m € P[n].toSend 


eff 
P[n].toSend := delete(m, P[n].toSend) 
C[ni].contents := insert(m, C[n1].contents) 


output overflow(iit, s; local n:Int, 
P:Map[Int, Locals[P, overflow]], 


W:Locals[Watch, Int, overflow]) 
where 1 <n An < nProcesses A it =nA 
i1 € between(1, nProcesses) > (s = W.s2 U {il} V n(Cil € s)) 
pre 1 <n A n< nProcesses A il=nvA 
s = P[n].toSend A n < size(s) A P[n].t Cs 


eff P[n].toSend := P[n].t 
if s = W.s2 U {ii} then W.seen[ii] := true 
elseif =(i1 € s) then W.seen[i1i] := false 
fi 


output found(il) 
pre ii € between(1, nProcesses) A W.seen[il] 


Figure 8.5: Output transition definitions of SysExpanded 
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output receive(ni, n2, m) 
pre m € C[ni].contents 


eff 

C[ni].contents := delete(m, C[n1].contents) 

if P[n2].val = 0 then P[n2].val :=m 

elseif m < P[n2].val then 
P[n2].toSend := insert(P[n2].val, P[n2].toSend) ; 
P[n2].val :=m 

elseif P[n2].val < m then 
P[n2].toSend := insert(m, P[n2].toSend) 


fi 


output send(ni, n2, m) 
pre m ©€ P[ni].toSend 


eff 
P[ni].toSend := delete(m, P[ni].toSend) 
C[ni].contents := insert(m, C[n1].contents) 


output overflow(il, s; local P:Map[Int, Locals[P, 


W:Locals[Watch, Int, 
where s = W.s2 U {il} V (il € s) 


overflow], 
overflow] ) 


pre s = P[ii].toSend A it < size(s) A P[i1t].t Cs 


eff P[i1l].toSend := P[ii].t 
if s = W.s2 U {ii} then W.seen[ii] := true 
elseif =(i1 € s) then W.seen[i1i] := false 
fi 


output found(il) 
pre W.seen[ii] 


Figure 8.6: Simplified output transition definitions of SysExpanded 


77 


internal send(ni, n2, m) 
pre m ©€ P[n1i].toSend 
eff 

P[n1].toSend 

C[n1].contents 


P[ni].toSend) 


:= delete(n, 
C[{ni].contents) 


:= insert(n, 


Figure 8.7: Internal transition definitions of SysExpanded 


The final transition of SysExpanded is shown in Figure 
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9 Renamings, Resortings, and Substitutions 


In this section, we give formal definitions for resortings and variable substitutions in IOA. 


9.1 Sort renamings 


A sort renaming or resorting is a map from simple sorts to sorts|?>| Any resorting p extends 
naturally to a map /f defined for all simple sorts by letting p be the identity on elements not in the 
domain of p. In turn, # extends further to a map fp from sorts to sorts by the following recursive 
definition: 


ne p(T) if u is a simple sort T, and 
U) = 
T[p(T1),---,P(Tn)] if wis a compound sort T|T};,..., Th]. 


Let ps_.r denote a resorting that maps the sort S to sort T’ and is otherwise the same as p 
(even if S' is already in the domain of p). 


9.2 Variable renamings 


A variable renaming pq is an extension of a resorting p that maps variables in a sequence q to 
distinct variables. If v is a variable i:T’ in q, then p,(v) is defined to be j:((Z) where j is an 
identifier (7 itself, if possible) such that 7:6(T) 4 pq(v’) for all variables v’ that precede v in g. We 
say that pg is a variable renaming with respect to precedence sequence q. 

If p, is a variable renaming where r = q||p then we say p, is an extension of pq with respect to 
precedence sequence p and we write that py = pq | p. 


9.3. Operator renamings 


An operator renaming w is a map from operators to operators that preserves signatures. Any 
operator renaming w extends naturally to a map w defined for all operators by letting w map each 
operator not in the domain of w to itself. 

We extend any operator renaming w further to a map w on some syntactic elements of an IOA 
automaton (terms to terms, statements to statements, etc.) We now define & for each type of IOA 
syntax to which it may apply. 


Terms and sequences of terms 


If u is a term, then (uw) is 
e vu, if u is a variable v, 
e w(f)(W(u1),...,@(un)), if wis aterm f(w1,...,Un) for some operator f and terms w1,..., Un, 


e Vu wu’), if u is a term Vv (u’) for some variable v and term u’, and 


e Ju &(w’), if wis a term Jv (u’) for some variable v and term uw’. 


If g is a sequence of terms {uj, U2,...,Un}, then &(q) is {W(u1),o(u2),...,@(un)}. 


25Tn IOA, sorts are divided into simple or primitive sorts, such as Int and T, and compound or constructed sorts, 
such as Set [T] and WeightedGraph [Node, Nat]. 
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Values 
If 1 is a value, then d(l) is 
e w(t), iflis aterm t 


e choose v where (p), if | is a choice choose v where p for some variable v and predicate p. 


Statements and programs 
If s is a statement, then w(s) is 
e w(lhs) := (rhs), if s is an assignment lhs := rhs for some lvalue [hs and some value rhs, 


e if &(p,) then &(s,) elseif @(p2) then...else W(s,,) fi, if s is a conditional statement 
if p; then s, elseif p2...else s,, fi for some predicates p1,..., Pn—1 and statements s1,..., Sn, 
and 


e for v where &(p) do &(g) od, if s is a loop statement for v where p do g od for some 
variable v, predicate p, and program g. 


If g is a program $1; 59;..., then &(g) is W(s1);W(s2);.... 


Shorthand tuple sort declarations 


If w is an operator renaming and d, and dz are two shorthand tuple sort declarations: 


dy = T tuple of 71:7), i9:To,...,and 
dg = T tuple of 71:71, 72:To,..., 
where 71, 22,..., and jj, jo,..., are identifiers and T,, 7), T>,..., are sorts then we write wg,—.d, OF 


WT fi1 2,...}{j1,J2,...} for the operator renaming that maps 
1. tuple selection operators __.i,:T — Ty, to __.jp:T — T),, and 


2. tuple set operators set_iz:T, 7, — T to set_jp:T, Ty,  T. 


9.4 Renamings for automata 


In Section [5|we defined resortings that map types“ to actualTypes?’“ for some desugared automaton 
A with formal type parameters types“ instantiated with actual type parameters actual Types? o 

Let p be such a resorting and @ be the variable renaming py,;. We extend @ to a map @ on 
some syntactic elements of an IOA automaton (terms to terms, statements to statements, etc.) by 
defining @ for each type of IOA syntax to which it may apply. 


Automata 


If A is desugared primitive automaton with syntax as given in Section |4|and shown in Figure |4.5} 
then 0(A) ig?)| 


6 Strictly speaking, the definition of the automaton 0(A) is not a legal definition of a primitive IOA automaton. Its 
type parameters, shown as types“, should really consist of the non-built-in types that appear in sorts in o(types*). 
Furthermore, the declared state variables may not match the aggregate state variable selectors that appear in terms 
in signature where clauses, in the initially clause, or in transition definitions. 


80 


automaton A(6“(vars4); types“) 


signature 
kind 7(64*(vars4)) where 647(P/i7) 


states p(state Vars“) := 64(init Vals“) initially 64(PA,,) 


anit 


transitions 


kind r(vars4*; local local Vars‘:",) where PA” 


kind,ty 
Ayr Ayr 
Okind,t pre Prenat; 
fF P Ayr : - Ayr | 
eff Prog) 44, ensuring ensuring; ina 1, 


where 


1. 64 is a variable renaming 6+ ({A, A’:States[A, types4]}|| vars4|| state Vars4|| postVars4) 


2. 64:7 is a variable renaming 64+ vars47. 


-Ayr < $ . 
3. Ope g 4, 8 a variable renaming 


64.7 F ({A, A’: Locals[A, types“, kind, r]}|| local Vars‘™ | localPost Vars",) P5| 


Transition definitions 


Let t be a transition definition in automaton A as given above. That is, ¢ is 


‘ A,r. Ayr 
kind r(vars“"; local localVars;,;",) case c where p; 


pre p2 


eff g ensuring p3 
where vars“: is a sequence of variables, localVars, = {11:Tj,7i9:To,...,} is a sequence of vari- 
ables, pi, p2, and pg are predicates, and g is a program. Let S be the aggregate local sort 
Locals|A, types“, kind, 7] of t, and © be the variable renaming Cea given above. That is, 6 
is an extension of p with respect to the precedence sequence {A, A’: States[A, types4]}|| vars4|| 

state Vars“|| post Vars“|| vars4:"|| (A, A’:Locals[A, types“, kind, x]}1| localVars‘..™ | localPostVars‘",,. 


27Fven though variables in stateVars“ and postVars“ do not appear in any terms in a desugared automaton 
definition, we include those variables in the precedence sequence to ensure that selectors for local variables do not 
clash with selectors for state variables in transition definitions (see below). 

8Like state variables, variables in local Vars<™, and localPost Vars*", do not appear in any terms in a desugared 
automaton definition. We include those variables in the precedence sequence only to ensure that selectors for local 


variables do not clash with each other. (see below). 
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We define @(t) to be 


3s 


kind 1(6(vars4”); 6(localVarst,)) case c where (99) £4, 42,...}—{j1,j2,... } (O(P1)) 
pre Wo(S),fi1 2... jo {G1 325+ }(0(p2)) 
eff (2 5( 5), {41 2,... } Frio }(O(G)) Ensuring Wp(3),4512,...} {jr jo... } (O(P3)). 


vis 


where 6(local Vars,) is a variable sequence {j1:0(T1), j2:e(T2),...,}. Note that if localVars, = 
6(local Vars‘,), then w»(),f4,,i2,...}—{j1,j2,...} 18 the identity operator renaming. 


Statements and programs 


If s is a statement and @ is some variable renaming, then @(s) is 
e o(lhs) := 0(rhs), if s is an assignment /hs := rhs for lvalue lhs and value rhs, 
e if o(pi) then 6(s,) elseif o(p2) then...else 6(s,) fi, if s is a conditional statement 
if p; then s, elseif po...else s, fi for some predicates pj,..., Pn_1and statements s1,..., Sn, 


and 


e for 0'(v) where 6'(p)do 6'(g) od, if s is a loop for v where p do g od for some variable v, 
predicate p, and program g, where 6’ = @t {v}. 


If g is a program $1; 89;..., then @(g) is 6(51); 0(s2);.... 

Values 

If J is a value and g is some variable renaming, then (I) is 
e o(t), ifl is a term t, and 


e choose 0/(v) where 0'(p), if | is a choice choose v where p for some variable v and predicate 
p, where @' = oF {v}. 


Terms and sequences of terms 
If u is a term and @ is some variable renaming, then @(u) is 
e o(v), if u is a variable v, 
e f(0(u1),..-,0(Un)), if wis aterm f(u1,..., Un) for some operator f and terms wj,...,Un, 


e Vo'(v) o'(u’), if wis a term Vv (u’) for some variable v and term wu’, where o' = a+ {v}, and 


e 46'(v) a (v’), if u is a term Jv (u’) for some variable v and term wu’, where o' = ot {v}. 
If g is a sequence of terms {w1,U2,...,Un}, then @(q) is {0(u1), o(u2),..., @(un)}. 
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9.5 Substitutions 


A substitution is a map from variables to terms such that the image of any variable has the same 
sort as the variable. Any substitution o extends naturally to a map o defined for all variables by 
letting ¢ map each variable not in the domain of o to a term that is a simple reference to the 
variable itself. 

Let oy; denote a substitution that maps the variable v to the term t and is otherwise the same 
as o (even if v is already in the domain of 0). We extend any substitution o further to a map @ 
on some syntactic elements of an IOA automaton (terms to terms, statements to statements, etc.). 
We now define o for each type of IOA syntax to which it may apply. 


Terms and sequences of terms 
If u is a term, then G(u) is 
e o(v), if u is a variable v, 
e f(G(u1),...,F(un)), if wis aterm f(ui1,...,Un) for some operator f and terms uy,...,Un, 


e Vw oysu(u’), if uw is a term Vv (u’) for some variable v and term u’, where w is a variable (v 
itself, if possible) with the same sort as v, where w ¢ FV(G(v’)) for all variables v’ € FV(u), 
and 


e dw Gyw(u’), if uw is a term Jv (u’) for some variable v and term u’, where w is as above. 


If q is a sequence of terms {u1, U2,...,Un}, then G(q) is {G(u1), (u2),...,F(Un) }. 


Values 
If 1 is a value, then G(l) is 
e a(t), if] isa term t 


e choose w where 6,_.~(p), if 1 is a choice choose v where p for some variable v and 
predicate p, where w is a variable (v itself, if possible) with the same sort as v, and where 
w ¢FV(G(v’)) for all variables uv’ € FY(I). 


Statements and programs 


If s is a statement, then G(s) is 
e o(lhs) := G(rhs), if s is an assignment /hs := rhs for some lvalue lhs and some value rhs, 


e if G(p1) then G(s) elseif G(p2) then...else G(s,) fi, if s is a conditional statement 
if p; then s, elseif po...else s, fi for some predicates p1,..., Pn—1 and statements s1,..., Sn, 


e for w where G,_.~(p) do Gyw(g) od, if s is a loop statement for v where p do g od for 
some variable v, predicate p, and program g, where w is a variable (v itself, if possible) with 
the same sort as v, where w ¢ FV(G(v’)) for all variables vu’ € FY(s). 


If g is a program $1; 89;..., then G(g) is G(51);G(s2);.... 
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Transition definitions 


If, in automaton A parameterized by type parameters types“, t is a transition definition 


kind 2(params’; local v1, v2,...) case c where p; 
pre p2 


eff g ensuring p3 


where params” is a sequence of terms, v1, v2,... is a sequences of variables 74:71, 79:T2,..., P1, pa, 
and p3 are predicates, g is a program, and S is the aggregate local sort of t, then a(t) is 


kind 1( 64, 09,...} +{w1,w,...}(params™); local w}, w2,..-) 
case c where Wg §5, 42... } {jy 490,...} (F {v1 ,v9,... }> {wi wo,... } (P1))) 
DIC Wai 8 Nie, AO hago 1 aa Ae) 
OM giao eps WO aes 8 esac ag) ) 


ensuring WS, 41 i2,... l{jijoy. NioJere es }{w1,we,..- }(p3))) 
where 
1. wx is a variable j;,:T;, (vz itself, if possible), and 


2. we ¢ FV(G(v’)), for all variables v' € { A, A':States[A, types4]} U stateVars4 U postVars4 U 
vars‘ U FV(params™) U {A, A’:Locals[A, types“, kind, 7, c]} U {u,v} | 1 < k}. 


Note that if 7, = jj, for all k, then wg ¢j, 2,...}451,J9,...} 18 the identity operator renaming. 


cre 
Hidden clauses 
If c is a clause in a hidden statement 
™(params” ) where p 
where params” is a sequence of terms and p is a predicate, then G(c) is 
TCG Gig ain bs Caused <b DOTONIS” ) eg WOT OO Faas 5 Vale gins) AUD) 
where 
1. vp is a variable ip:T;, € FV(params™ ) 
2. wz is a variable (vz, itself, if possible) with sort T; 


3. we ¢ FV(a(v’)) for all variables vo’ € FV(params™) U FV(p) U {uy | lA k}. 


9.6 Notation 


Except in definitions such as these, we do not employ separate notations for the extensions /, /, 
Pw, Pq, and @ of a resorting p. In particular, when applying a resorting p to an IOA automaton A, 
we write p for @. Similarly, we do not distinguish 6 and o from a substitution o and we write o for 
G. 
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